Announcement

Collapse
No announcement yet.

Using LLVM As The Compiler Within Fedora?

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

  • #11
    Originally posted by mark_ View Post
    I claim that it might be very convenient for the programmer to choose such extensions, but as I said, there is a price. If you stick to the standard, you don't pay the price and your users don't pay it either.
    Of course, but again it is a programmer's decision. I'd rather have a compiler giving me these features and only use them when I feel I need them, rather than not having them because someone like you decided it didn't fit their vision of 'what I need'.

    Originally posted by mark_ View Post
    I don't think, that there are really good technical reasons for using the gcc extensions, BSD obviously works without them and I bet their code and their performance did not get worse.
    And I bet the kernel devs didn't request these extensions and then use them throughout the kernel without good reason, I know the Linux kernel code relies heavily on compiler extensions which allow it to have better control over branch prediction and cache lines which certainly has a great impact on performance.

    Originally posted by mark_ View Post
    Btw, just for fun let's exaggerate your argument, that gcc is free and therefore implementing a dialect is ok:
    What if I write 100 free programs and you want to use them all...
    That you would need to paint a gross exaggeration in order to make it into a problem only shows how little water your argument holds. If you want to adhere to standards YOU as a PROGRAMMER choose to do so, if you don't then the compiler allows YOU to make that choice and use compiler extensions.

    Originally posted by mark_ View Post
    So: if you want to justify excessive use of a language extension to me, create an official standard like GNU C first. Then your program uses GNU C which is not C and then I have no problem anymore, if clang cannot compile your code.
    First off, in that case you must shun Clang/LLVM, not only does it have support for alot of GCC's extensions but it also has it's OWN EXCLUSIVE extensions which is not supported by any other compiler and thus 'forces' the you to compile it with Clang/LLVM, heck it's even mentioned in the very thread this 'article' points at. So with your arguments you are against BOTH GCC and Clang/LLVM, yet you only level criticism at GCC. Either you are just hypocritical or you simply lived in some fuzzy belief that Clang/LLVM only implemented 'standard' functionality.

    Secondly by it's very nature and as made obvious by their name, extensions AREN'T standards, they are 'extensions' to existing standards, how can you fail to grasp that? And those who use these 'extensions' do so because they really feel they need what they offer, knowing full and well that there is no guaranteed compability across compiler toolchains given that they are NOT standards.

    Also, you do realize that most of the features in later standards started as extensions and then elevated into standard functionality when they had proven their worth and stability?

    In conclusion, both GCC, Clang/LLVM, Intel Compiler implements compiler _extensions_ which offer functionality beyond what the standards define. These _extensions_ are not supported across all compilers although some are, GCC has exclusively supported extensions, Clang/LLVM has exclusively supported extensions and same goes for ICC.

    I find it hard to believe you are a programmer at all, you sound like a person who just compiles other people's code and throws a fit if it doesn't compile with *your* favourite compiler. And if you feel you have a legitimate reason to complain then you should take those complaints to the actual programmers who CHOSE to USE these extensions, not to the compiler vendors who make them available at the request of those same programmers. And you should certainly not single out GCC as some culprit, because all these compilers implement extensions and each with their own exclusive ones.

    Comment


    • #12
      Originally posted by kraftman View Post
      it can't compile many packages
      That's the fault of the person coding the "package" not the compiler.

      Comment


      • #13
        Originally posted by yogi_berra View Post
        That's the fault of the person coding the "package" not the compiler.
        I'd disagree there.. The reason GCC has those extensions is because the standard is inadequate and it's not GCC's problem that the standard is inadequate..

        If you make a compiler that meets just the standards instead of making what people actually need, you've made something that's a whole heap of worthless.

        The assumption that the standards are good enough is obviously incorrect as if that was true then there would be no need for extensions.
        Last edited by Sidicas; 16 February 2012, 04:57 PM.

        Comment


        • #14
          Originally posted by Sidicas View Post
          I'd disagree there.. The reason GCC has those extensions is because the standard is inadequate and it's not GCC's problem that the standard is inadequate..

          If you make a compiler that meets just the standards instead of making what people actually need, you've made something that's a whole heap of worthless.

          The assumption that the standards are good enough is obviously incorrect as if that was true then there would be no need for extensions.
          Further on, some of the things only supported by compilers later on becomes included as parts of the standard.

          Comment


          • #15
            Originally posted by Sidicas View Post
            I'd disagree there.. The reason GCC has those extensions is because the standard is inadequate and it's not GCC's problem that the standard is inadequate..

            If you make a compiler that meets just the standards instead of making what people actually need, you've made something that's a whole heap of worthless.

            The assumption that the standards are good enough is obviously incorrect as if that was true then there would be no need for extensions.
            Hey, if you want to write platform specific code and recreate vendor lock-in on Linux, feel free. Just don't claim that your program is open, free, or portable.

            Comment


            • #16
              Originally posted by yogi_berra View Post
              Hey, if you want to write platform specific code and recreate vendor lock-in on Linux, feel free. Just don't claim that your program is open, free, or portable.
              Just stop trolling, first off the extensions are not platform specific, you can use them on Windows aswell, and again ALL compilers have extensions not available in other compilers, for example Microsoft just introduced another set of extensions for C++ called AMP which is for accelerated massive parallelism and only available for Visual Studio which unlike GCC and LLVM/Clang really IS a platform specific compiler.

              And while compiler extensions can prevent code from being portable between compilers, how will it make open source not 'open' or free open source not 'free'? Your ignorance and Linux hatred seems to know no bounds, certainly reality has no effect on it.

              Comment


              • #17
                For those wanting to see another polarized discussion
                I don't see that at all.

                What I see is:

                One Guy: "Hey I heard about this thing and I want you do to a bunch of really hard, time consuming, and irritating work to see if we can do something in a worse way then you already do!"

                Rest of them: "Uhhh... no."

                Comment


                • #18
                  ISTR that some of gnu89 wound up in C99, and some of gnu99 ended up in C11 (I think I saw it in one of the man pages...).
                  Which means that today's gnu extensions are tomorrow's standard.

                  One person ( developer working on compiling Linux with LLVM) mentioned that while LLVM can build a minimal kernel, it can't even make a bootable no-op kernel.

                  A number of "kernel bugs" were related to compiler optimizations that did the wrong thing (eg, null pointer check got optimized out); the fix was to put in a directive that disabled the optimization there. Just because GCC did the wrong thing and a bug was found in one use, doesn't mean that noone else will make the same mistake; the tricks work in certain other contexts, so the GCC developers aren't reverting them. Thus you end up using extensions to work around a slightly broken compiler.
                  When someone offers you a compiler which, for your purposes, is even more broken (isn't Apple is supporting OSX and not Linux?), but doesn't have all the methods to workaround stuff semi-sanely, you would end up getting more breakage if you support it: first, you lose fixes for your own compiler; second, people try the other compiler, it doesn't work right, and there aren't as many people working on the project using either compiler as there were using the one compiler you started with (If you start with 100 programmers, and 20 switch, and 10 join them, you have 80 people to support one and 30 to support the other, so you get breakage on one or the other, or fixes get hung up, and you get some bitrot in the less-used compiler branch).

                  Comment


                  • #19
                    There's a bit of a middle ground here

                    Using compiler extensions when they aren't needed really is a bad thing. Using them when they are needed, is not.

                    Clang already supports many of the GCC extensions because everyone recognizes that they are useful, and it's nice for the two projects to be compatible. They've also said that a few were poorly designed and will not be implemented.

                    As LLVM matures compatibility will continue to increase, and I haven't really seen any projects that are refusing to take contributions to fix up Clang compatibility. If something isn't working correctly, just patch the project with #ifdefs to get it working. That's one of the benefits of being open source, that anyone with an interest can go in and fix up their pet peeves.

                    Comment


                    • #20
                      Originally posted by XorEaxEax View Post
                      Of course they are useful, and the reason they were added was at the behest of programmers
                      Not likely. Most language extensions in GCC are legacy stuff. It's hard to get new extensions in, because most extensions are stupid and are just little tweaks to turn a 4 line piece of code into a 3.5 line piece of code, and the developers have since wised up. Many of the old extensions were added because some developer or another thought it would be a "cool feature" and just slapped it in without thinking through the ramifications.

                      This is the problem with almost every major language outside the C/C++/C# family: they're filled to the brim with half-thought-out idiocy that some so-called compiler expert dropped in because the idea popped into his head. Rarely are these features analyzed to see just how generic, safe, or consistent they are. Everyone who pretends to be a compiler expert seems to be obsessed with writing excessively terse (read: unmaintainable) code and adding syntactic sugar to make it happen. Craziness.

                      I can't recall ever having use of anything other than the gcc vector type extensions
                      There's no reason to use those. Use the standardized CPU intrinsics. (Yes, they are standardized by Intel/ARM/IBM.)

                      Is C99 necessary? C11? C++11?
                      Yes. Those language updates explicitly add features that allow the programmer or compiler to do things that were literally _impossible_ to do before. The standards committees that are now in charge of those languages (C++ was for a long time under no such authority, and some of the goofier bits of the language appeared during those years) are full of a lot of very smart people, who are _very_ conservative in what they add to the languages, and they only do so when there is truly remarkable utility in doing so.

                      Should programmers not use the features offered by them if their compiler supports it because say VS2010 doesn't support them fully?
                      If they want to target MSVC 2010, then no, they should not.

                      Should programmers not use Win32 APIs if their OS (Linux) doesn't support them fully?

                      And for the record Clang supports lots of extensions, so it's not 'pure' by any means.
                      And not just random extensions (it has an unfortunate number of those too) but is being used as a testbed for features that will be proposed to the committees. Which is one of the reasons why dipshits who think Clang is just "Apple crap" are dipshits. Clang has a LOT of incredible benefits over GCC. The fact that it can't compile every random low-quality FOSS crap package, or the fact that it does not _yet_ optimize as well as a much older compiler, is of little importance to some users. The fact that it's massively easier to alter and extend, that it provides incredibly more logical error messages, that it allows much richer plugins and non-compiler uses than GCC, that it was designed to be easy to use for editors and tools (which are more important than the compiler itself, IMO, and in the common opinions of anyone who actually maintains large and complex codebases)... these are why Clang is so awesome.

                      Should Fedora switch to using it by default? No. As the Fedora folks said, there's little reason at this point in time. Clang is in the Fedora package repo, and the people and projects and tools that can make good use of it do so.

                      Comment

                      Working...
                      X