Announcement

Collapse
No announcement yet.

Fedora To Remain Monogamist Towards GCC

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

  • Fedora To Remain Monogamist Towards GCC

    Phoronix: Fedora To Remain Monogamist Towards GCC

    While FreeBSD 10 is preparing to fully switch to LLVM's Clang compiler and deprecate GCC, don't expect such a compiler change to happen in the Fedora camp in the foreseeable future. Fedora engineers have issued a statement reaffirming their commitment to GCC and stance on "alternative compilers" within this Red Hat distribution...

    http://www.phoronix.com/vr.php?view=MTEwMzI

  • #2
    I think LLVM does have future potential.
    But right now, I do think GCC produces better results in the real world.

    I think they should keep on using GCC, while also compiling everything with LLVM to make sure everything compiles cleanly.
    Compiling with more than one compiler makes it better.

    Comment


    • #3
      A wise decision

      A wise decision from RH engineers.
      While LLVM has some tractions in the JIT compiler area, it doesn't present any clear advantage for replacing GCC in a standard toolchain.
      hobbyists can still install it if they want to test their code with it anyway.

      Comment


      • #4
        Looks like they accidentally banned OpenJDK/IcedTea in favor of GCC’s Java compiler…

        Comment


        • #5
          Originally posted by Awesomeness View Post
          Looks like they accidentally banned OpenJDK/IcedTea in favor of GCC’s Java compiler…
          If you read part of the log it will be clear to you that the statement in favour of GCC is only valid for stand alone toolchain compilers like clang. For JIT purposes llvm is still the way to go, otherwise they also would have to ditch llvmpipe is MESA, which is not what will happen.

          Comment


          • #6
            Originally posted by Lynxeye View Post
            If you read part of the log it will be clear to you that the statement in favour of GCC is only valid for stand alone toolchain compilers like clang. For JIT purposes llvm is still the way to go, otherwise they also would have to ditch llvmpipe is MESA, which is not what will happen.
            I've read the log and yes, in context it's clear. However, there was a one sentence long policy voted upon which does not have any references to that. (“Packages may only build with an alternative compiler to gcc if upstream does not support gcc”)

            And no LLVMpipe is not used to produce any packages. The policy as it was voted, seems to ban OpenJDK/IcedTea for all uses that GCC’s Java compiler can handle.

            Comment


            • #7
              Has nobody noticed that this nonsense is all about licensing?
              LLVM is licensed basically BSD, which is why BSD's will prefer it -- it allows for anti-competitve use.
              GCC is GPL.

              Comment


              • #8
                Originally posted by droidhacker View Post
                Has nobody noticed that this nonsense is all about licensing?
                LLVM is licensed basically BSD, which is why BSD's will prefer it -- it allows for anti-competitve use.
                GCC is GPL.
                It would be funny, if GCC took code from LLVM. Can you imagine this irony?

                Comment


                • #9
                  I have no idea what the purpose of the monogamy/cheating quip was, other than to put some sort of spin on this, but really it's the same thing as with FreeBSD, only that Fedora will ship GCC while allowing anyone to use Clang/LLVM and also use it for packages should they require it and FreeBSD will ship Clang/LLVM while allowing anyone to use GCC, it's right there in ports.

                  Also I can't see any reasons why Fedora would switch to Clang/LLVM, it doesn't even compile the Linux kernel. Furthermore it fails at compiling lots of other key packages like LibreOffice etc, not to mention supporting less languages and less hardware targets. FreeBSD switching official compiler to Clang/LLVM on the other hand made perfect sense as they were stuck with 5 year old GCC 4.2 due to their corporate sponsors not accepting GPLv3.

                  Comment


                  • #10
                    Originally posted by XorEaxEax View Post
                    Fedora will ship GCC while allowing anyone to use Clang/LLVM and also use it for packages should they require it
                    This is what I do not understand about this policy: Why not let the packager decide which compiler works better for the package?

                    Comment


                    • #11
                      Originally posted by Awesomeness View Post
                      This is what I do not understand about this policy: Why not let the packager decide which compiler works better for the package?
                      imagine the anarchic mess resulting of bugs report present in LLVM/Gcc and not present in the other that without account possible abi breaks, longer time to fix bugs or the dude maintaing the package simply got bored and leave the package unmaintained and the next one have to figure out how to solve stuff from clang/llvm since not much ppl is experienced with it unlike gcc.

                      beside clang/llvm don't have feature parity with gcc nor offers better performance (i don't mean cute build logs i mean AVX/FMA, PGO, LTO, Graphite, OpenMP(<--for god sakes), etc).

                      beside this is a policy for main distro packagers it doesn't mean you can download clang and compile your X favorite app with it and publish in your X prefered Repo.

                      llvm/clang is a nice project but is not prime time ready nor is ready to replace GCC at least for 2 more years

                      Comment


                      • #12
                        Originally posted by jrch2k8 View Post
                        imagine the anarchic mess resulting of bugs report present in LLVM/Gcc and not present in the other that without account possible abi breaks, longer time to fix bugs or the dude maintaing the package simply got bored and leave the package unmaintained and the next one have to figure out how to solve stuff from clang/llvm since not much ppl is experienced with it unlike gcc
                        So then they can switch the package back to GCC if Clang actually causes problems.

                        Originally posted by jrch2k8 View Post
                        llvm/clang is a nice project but is not prime time ready nor is ready to replace GCC at least for 2 more years
                        Yeah right, that's why Apple uses Clang for its “not prime time” iPhones and Macs….

                        Comment


                        • #13
                          Originally posted by Awesomeness View Post
                          So then they can switch the package back to GCC if Clang actually causes problems.


                          Yeah right, that's why Apple uses Clang for its “not prime time” iPhones and Macs….
                          1.) if that happens still is lot more work than just keep 1 well tested toolchain (which is their point to begin with) assuming the previous maintainer didn't use clang specific optimization which are not supported or cause regressions in gcc which adds to the fun of maintain many toolchains

                          2a.) Mac is mostly Objetive C where Linux is GNU/ISO C and C++(except maybe libre/open office)
                          2b.) Mac is extremely tied to very specific hardware so they can uber ultra optimize their clang code(reads not neccesatily available since clang in BSD licensed) where Linux run in almost any hardware known in these galaxy and even when you specify a target plataform like x86(and variants) you have to support several vendors (amd/intel/others) specific architectures and extensions/features(AVX/FMA/XoR/cache/etc) efficiently(and Michael has proved again and again that GCC is way faster even using default flags, if you add proper falgs and PGO/LTO that difference tends mostly to get only bigger)

                          so even if Apple have their ObjC branch uber optimized for their very specific set of hardware my point is still true Clang is not ready for prime time in the Linux world neither is more efficient or the binaries are faster than GCC and Clang only support a small subset of plataforms compared to GCC.

                          again im not saying llvm/clang sucks, i am saying it need to mature a lot more to be a real GCC replacement cuz today is a nice proof of concept with a nice future ahead but is not in the same league as GCC is

                          Comment


                          • #14
                            A couple side points:
                            * The LLVM/Clang/etc that Apple uses will never be the same LLVM/Clang/etc that everybody else uses.
                            * Also if you use LLVM/Clang/etc you can run into situations were things that are legal for Apple to do is illegal for you to do because of Apple's licensing agreements.

                            After all then why the hell would Apple want to run away from GPLv3 code? It's all about the patents that Apple controls, of course.


                            This is what I do not understand about this policy: Why not let the packager decide which compiler works better for the package?
                            Because the packager is not in a position to know what is best for the software. They are the packager, not the developer. In addition the use of alternative toolchains has a cascading effect on the rest of the system. In the end it will create maintenance headaches and other unnecessary crap that everybody else will have to deal with.

                            If the package maintainer wants to use LLVM then the correct way to approach it would be to get involved in upstream development and work with them to port their code base over to using LLVM. THEN the appropriate compiler to use for the application would be LLVM and not GCC, and thus easily meet Fedora's criteria.

                            That is the correct approach. If you are going to fuck around with alternate configs and compilers and all sorts of other development decisions then the appropriate place to do that is with the developers, upstream. Not the package making level.

                            Comment


                            • #15
                              Originally posted by drag View Post
                              A couple side points:
                              * The LLVM/Clang/etc that Apple uses will never be the same LLVM/Clang/etc that everybody else uses.
                              * Also if you use LLVM/Clang/etc you can run into situations were things that are legal for Apple to do is illegal for you to do because of Apple's licensing agreements.

                              After all then why the hell would Apple want to run away from GPLv3 code? It's all about the patents that Apple controls, of course.




                              Because the packager is not in a position to know what is best for the software. They are the packager, not the developer. In addition the use of alternative toolchains has a cascading effect on the rest of the system. In the end it will create maintenance headaches and other unnecessary crap that everybody else will have to deal with.

                              If the package maintainer wants to use LLVM then the correct way to approach it would be to get involved in upstream development and work with them to port their code base over to using LLVM. THEN the appropriate compiler to use for the application would be LLVM and not GCC, and thus easily meet Fedora's criteria.

                              That is the correct approach. If you are going to fuck around with alternate configs and compilers and all sorts of other development decisions then the appropriate place to do that is with the developers, upstream. Not the package making level.
                              100% true and apple has their private branch of clang/llvm for their use only not just cuz the issues drag mentioned but the fact of they have their propietary Next/Os X unix specifics embedded in that codebase

                              Comment

                              Working...
                              X