Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: Formalizing The LLVMLinux Project: Clang'ing Kernels

  1. #11
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    965

    Default

    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

  2. #12
    Join Date
    Feb 2008
    Posts
    37

    Default GCC's compilation stages

    Quote 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?

  3. #13
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by Ericg View Post
    C++ just got updated for 2011, and I heard something about an updated C standard),
    http://en.wikipedia.org/wiki/C11_(C_standard_revision)

    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).

  4. #14
    Join Date
    Oct 2010
    Posts
    322

    Default

    Quote 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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •