Announcement

Collapse
No announcement yet.

Formalizing The LLVMLinux Project: Clang'ing Kernels

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

  • #11
    If a Clang'ed kernel can be built *without* any major patching (with exceptions of fixing any code constructs that are workarounds for gcc-specific issues) as well as the resulting object code being tighter and faster then I can call Clang a success

    Comment


    • #12
      GCC's compilation stages

      Originally posted by Ericg View Post
      2) Clang has better diagnostics ( i know GCC 4.7 has very much improved ones, but while they were working on fixing their own, im sure Clang made theirs even better). Which means that build errors are more easily spotted, also Clang (and LLVM) compiling is done in stages, so if someone needs to jump into the middle of the compilation process they can do it with LLVM, with GCC you give it the code, hit compile and cant intervene in any way until you have the binary.
      Just add "-fdump-ipa-all -fdump-tree-all" option to GCC and it will fill the working directory with ~100 files, one for each stage. How many stages does Clang/LLVM have?

      Comment


      • #13
        Originally posted by Ericg View Post
        C++ just got updated for 2011, and I heard something about an updated C standard),


        if the extensions are truely good ideas then thy should be integrated into the standard. Which Clang would then support anyway.
        Many of the extensions will never be in a C standard. Part of the reason is that C is even more conservative than C++. Another reason is that many of those extensions are very specific to how GCC/GNU does things and are not relevant outside of Linux/GNU and compilers specifically targeting them, and some are even architecture specific (like the inline assembler "extensions" in GCC) and so have no place in the general C standard. Yet another reason is that C++ already does some of the things that various C extensions do, but does them better and in a more generic fashion, and there's no reason to extend C in ways that anyone not suffering from Linus's blind bigotry can just use C++ for instead.

        Many of the extensions which actually are applicable to general C have already ended up in various C standards. You can find some GCC-innovated extensions in both C99 and C11, and possibly C89/90 as well.

        There are certainly a few more that could move over, but we're not likely to see another C standard up for a very long time. C++ is trying to ramp up their release schedule after the embarrassingly long C++11 cycle, but there is little movement to make any improvements to C at a brisk pace. Particularly as all of the major OSes aside from Linux have long since stopped pretending that C is the ideal programming language, what with Microsoft not even supporting anything newer than C89 and (quite successfully) pushing C#, and with Apple pushing their Objective-C advancements, and with Google working to convince everyone that the Web is the future of everything ever forever (and otherwise being huge C++/Clang proponents for any native needs).

        Comment


        • #14
          Originally posted by Ericg View Post
          with GCC you give it the code, hit compile and cant intervene in any way until you have the binary.
          You clearly have no idea what you're talking about as gcc doesn't generate binaries, they generate assembly code that the assembler turns into binary objects, but humor me, what did you think you were talking about?

          Comment

          Working...
          X