Announcement

Collapse
No announcement yet.

GCC 11 Will Likely Support Using LLVM's libc++

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 11 Will Likely Support Using LLVM's libc++

    Phoronix: GCC 11 Will Likely Support Using LLVM's libc++

    While GCC 10 isn't even out for a few more weeks, looking ahead to next year's GCC 11 release is already one interesting planned change...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    The only criteria that is important to me is output executable performance. I did search for benchmark showing difference between gcc and clang yesterday and the only benchmark that I did find was only showing a very marginal difference giving a very small lead to gcc exec output. I'm currently using gcc to build C++ code. Unless I'm shown that LLVM libc++ is significantly faster than gcc own libs, I won't even bother to consider making the switch...

    Comment


    • #3
      I'm hoping this will also allow toggling the default C++ library. It would be great for FreeBSD / OpenBSD and OpenMandriva so the default is not so lame and dysfunctional with GCC. GCC is learning how to integrate.

      Comment


      • #4
        Originally posted by lano1106 View Post
        The only criteria that is important to me is output executable performance.
        In most cases, as you say, the differences tend to be on the edges (and/or very specific code that can show one, or the other, a strong winner).

        Unless I'm shown that LLVM libc++ is significantly faster than gcc own libs, I won't even bother to consider making the switch...
        Most people likely will not, but since some projects are using LLVM (and libc++), should you need to depend on their codes/libraries, or they need to depend on your codes, using just the one of libc++ or libstdc++ across the entire code base might have specific advantages.

        In any case, having the option to choose is a good thing going forward.

        Comment


        • #5
          Originally posted by lano1106 View Post
          The only criteria that is important to me is output executable performance. I did search for benchmark showing difference between gcc and clang yesterday and the only benchmark that I did find was only showing a very marginal difference giving a very small lead to gcc exec output. I'm currently using gcc to build C++ code. Unless I'm shown that LLVM libc++ is significantly faster than gcc own libs, I won't even bother to consider making the switch...
          LLVM is the future, because it is backed by Big companies. and sooner they will stop contributing to GCC.
          Apple, ARM, Nvidia, AMD, Intel, IBM and Cray have their own compilers based on Clang. Google switched years ago from GCC to Clang on Android.
          When these companies stop contributing to GCC, It will play a catch-up to support latest hardware.

          Comment


          • #6
            QNX has been shipping libc++ with GCC as an alternative for a few years now, going back to libc++ 3.7 and GCC 5.4. While the two libraries are different implementation and neither is bug-free, the only really substantial difference is the licensing and the development methodology. You can even configure libc++ to use the GCC C++ runtime (libsupc++) so the two libraries (libc++ and libstdc++) are interworkable in the same executable, with certain restrictions.

            When it comes to performance, the two implementations are roughly comparable down to the 4th significant digit, with a few areas being better in one than in the other. Standards conformance is roughly comparable.

            I can't see having a choice like this is a bad thing, especially if it means I have one less patch to carry against upstream. The only downside I can see is the increased support as people try to mix and match and they don't understand why their apps break at runtime.

            Comment


            • #7
              Originally posted by Setif View Post
              When these companies stop contributing to GCC, It will play a catch-up to support latest hardware.
              I worry more about the language improvements going forward. Adding the latest C++ standard feature often requires significant resources in both the compiler and the libraries. That is where corporate sponsorship of a strong compiler team tends to be the most visible.

              As I recall, one of the large companies still contributing important resources to gcc appeared to be RedHat.

              And, of course, it should be noted that (at least for now) while clang *can* compile the Linux kernel, it sill is compiled using gcc in all (known to me) distros, so gcc is still important, if primarily for the "C" part.

              I do recall seeing some email fly by regarding trying to improve the default cflag settings so that clang and gcc don't require so much hoop jumping in some distro packaging solutions, which would certainly make changing the default compiler viable at some point, if not likely any time soon.

              Comment


              • #8
                Originally posted by Setif View Post
                LLVM is the future, because it is backed by Big companies. and sooner they will stop contributing to GCC.
                Apple, ARM, Nvidia, AMD, Intel, IBM and Cray have their own compilers based on Clang. Google switched years ago from GCC to Clang on Android.
                When these companies stop contributing to GCC, It will play a catch-up to support latest hardware.
                The graveyard of dead tech mega-corporations is filled with the skeletons of companies that at one time contributed something or other to gcc or other projects. Anyone seen Novell lately? Sun? Transmeta? Transmeta used to pay Linus Torvalds a salary back in the 1990's and early 2000's to work on the kernel and their low-power x86 chips. Transmeta hasn't existed for many years. He went on to work for the Open Source Development Labs - which hasn't existed for many years now. Open Source Development Labs was founded by a number of corporations that now fill the tech graveyard, including Novell, SGI, Caldera (anyone remember the SCO vs IBM lawsuit?), Linuxcare, Turbolinux, and others.

                We've heard it all before. Mega-corp money comes and goes, and the community just keeps plowing forward. With or without their money or their demands for special favors.

                Comment


                • #9
                  To me it seems great forces are working to literally replace GCC. But this is also GCCs fault. GPL3 is too restrictive. It will be the bullet which will kill GCC.
                  Many really big projects moved away from it and new projects like Rust depend on LLVM. How long will GCC survive?

                  Comment


                  • #10
                    Originally posted by Steffo View Post
                    To me it seems great forces are working to literally replace GCC. But this is also GCCs fault. GPL3 is too restrictive. It will be the bullet which will kill GCC.
                    Many really big projects moved away from it and new projects like Rust depend on LLVM. How long will GCC survive?
                    If its unable to stay competitive, why does it matter if gcc survives or not?
                    If it stays competitive it will survive. Tbh, clang/llvm still has a lot issues outside of desktop, and mainstream architectures. I don't see gcc going anywhere for a long time, but if it's gone and another os compiler is taking its place I won't weep for a second.

                    Having to assign copyright for code to gnu, like gcc requires ain't helping (that's a lot worse than gpl3) . But thanks to the modular nature, llvm already went in a ton of previously substandard tools. Ie. Many Devs are already using clang/llvm even if the releases still are built with gcc

                    Comment

                    Working...
                    X