7 ms·

A few years ago, it was hard to imagine that there would be a breakout compiler that would get developers excited. It goes to show the value in competition and

A few years ago, it was hard to imagine that there would be a breakout compiler that would get developers excited. It goes to show the value in competition and a fresh perspective. Error messages, modularity, and licensing could unseat GCC, which is pretty amazing. (I know GCC still has many advantages, but clang/llvm clearly have made a lot of progress.)

npsimons 14y ago
More than a few years ago, it was very easy to imagine a breakout compiler getting developers excited. I think it was call "egcs" or somesuch . . . Joking aside, I'm glad for the competition, and for the options. It's always nice to have another automated way to audit code: throw another compiler with maximum warnings at it.
- protomyth 14y ago
  The most interesting thing for me is the library approach to the compiler. I wonder if it would benefit some other open source languages to restructure this way. It is a nice idea to be able to use the same compiler libraries in other tooling.
  - npsimons 14y ago
    While the separation of concerns in LLVM is laudable, I think that too many developers aren't even aware of some of the nice features in GCC. I was pleasantly surprised to find that Go support is now an option in building GCC, and I wouldn't be surprised if its fast adoption was in no small part due to the modularity of GCC (I've unfortunately not had the time to track development of GCC or LLVM for years). It still surprises me how many C/C++ developers don't know about _FORTIFY_SOURCE, -fstack-protector, or even -fmudflap. Consider also that coverage and profiling are builtin, and GCC offers a nice set of tools for professional software development. They're just not well advertised. I'm grateful for LLVM, but I wonder if some of the excitement over it is not just hype and it being the new hotness. EDIT: Can't believe I used "it's" instead of "its".
    - protomyth 14y ago
      I guess my question would be "Can I use the same parser that GCC uses in my tool?". I am most interested in that aspect of clang.
      - DannyBee 14y ago
        This is, in large part, something the FSF did not want to happen without the app being GPLv3. The other interesting thing is that this is only really an issue due to difficulty in properly parsing/semantically analyzing languages like C++. For languages like Java, it simply isn't necessary, or in some cases, desirable.
        protomyth 14y ago
        "For languages like Java, it simply isn't necessary, or in some cases, desirable." Why would it not be desirable? Also, if I have an idea for a great tool, why should I have to write my own parser? I have more faith the actual compiler will have bugs fixed quicker in this regard.
        mjn 14y ago
        If your goal is non-compiler analysis, like refactoring or verification, it's often more flexible to use a framework specifically designed to analyze source code and give you a nice AST with various options, rather than pulling the parser out of a compiler front-end. For languages with reasonably simple grammar there are usually one or more such packages, usually pretty well debugged. For example, for Java you could use http://spoon.gforge.inria.fr/ http://spoon.gforge.inria.fr/
        npsimons 14y ago
        As a counter-example/argument, CEDET/Semantic (http://cedet.sourceforge.net/semantic.shtml http://cedet.sourceforge.net/semantic.shtml) will use Clang/LLVM and/or GCC if you tell it to. It only makes sense, if someone has already gone to the trouble of not only writing a full up parser and lexer for your language, but also exposing things through modularization, you might as well use it.
  - drothlis 14y ago
    http://docs.python.org/2/library/ast.html http://golang.org/pkg/go/parser/ (See also gofmt: http://golang.org/cmd/gofmt/ and gofix: http://golang.org/cmd/fix/ )
- ajross 14y ago
  To be fair: egcs was a fork. It was a group of GCC people deciding that they wanted to work on the GCC code outside the control of the GCC project administration. And as it happened they were better at it and the FSF essentially took egcs back into the fold by handing over control of "GCC" to the forked project. LLVM/clang is a rather different thing, for both good and bad reasons.
pwg 14y ago
In a way there is some aspect of history repeating itself. The current compiler known as "GCC" is a direct descendant of an earlier GCC fork named EGCS: http://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fork http://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fo... So GCC was already "unseated" once, the difference being by a direct descendant instead of by a fully different compiler.
- pjmlp 14y ago
  Oh man, memories of having gcc and egcs both installed with different support levels for C++ :(
  - frozenport 14y ago
    And also running Gentoo unstable branch with that nonsense.
DannyBee 14y ago
It depends on what you mean by a few years ago. Even 5-6 years ago, it was clear to a bunch of GCC devs this was going to be the result :) The need and desire was very clear, and it was clear LLVM would meet that.
pjmlp 14y ago
What I find very positive about clang/llvm is: - Everyone now seems to be using LLVM for language prototyping instead of JVM/.NET, clearly positive for native compilation and to show people without compiler knowledge that managed != VM - The compiler as a library implementation of clang allows C, C++ and Objective-C to enjoy tooling support similar to JVM and .NET languages - As someone with a sweet spot for the strong typing found in the Pascal family, the integrated static analysis are just great
- hga 14y ago
  Does it have a good story for doing precise GC? When I looked at it some time ago, it appeared that I'd have to understand and write a lot of C++ code ... which I very much don't want to do.
  - pcwalton 14y ago
    No, LLVM's support for precise GC is not great. You can do it, but you have to spill all registers that might contain pointers across all calls, which is a significant performance hit. (Note that GCC is the same way though, as I understand it.) In my opinion, you're usually better off just doing conservative-on-the-stack GC if you're using LLVM. (This is what Rust does.) The basic problem is that LLVM loses the distinction between pointers and integers as soon as it drops into SelectionDAG and later passes. Fixing this would be a lot of work.
    - billwashere 14y ago
      Another cool LLVM based project that has Garbage Collection is the Epoch Programming Language[0] uses a similar approach [1]. Original reddit submission here [2]. [0] https://code.google.com/p/epoch-language/ https://code.google.com/p/epoch-language/ [1] https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme https://code.google.com/p/epoch-language/wiki/GarbageCollect... [2] http://www.reddit.com/r/programming/comments/1c5jz6/realistic_garbage_collection_on_top_of_llvm_epoch/ http://www.reddit.com/r/programming/comments/1c5jz6/realisti...
    - jules 14y ago
jjtheblunt 14y ago
What is an example advantage of gcc? (old parallelizing compiler person asking, but not working on such for years, randomly)
- stephencanon 14y ago
  OpenMP support.
  - jjtheblunt 14y ago
    Thanks.
  - emaste 14y ago
    Intel has recently released a permissively-licensed OpenMP runtime (http://www.openmprtl.org/ http://www.openmprtl.org/) though, and Intel's compiler team is working on OpenMP support (http://software.intel.com/en-us/forums/topic/391189 http://software.intel.com/en-us/forums/topic/391189, slides at http://llvm.org/devmtg/2013-04/bokhanko-bataev-slides.pdf http://llvm.org/devmtg/2013-04/bokhanko-bataev-slides.pdf) in Clang/LLVM using it. I suspect it won't be long before there's parity on this point.
belorn 14y ago
Is there any strong technical reasons why GCC can't just copy any useful features from Clang such as the improved error messages and put that into GCC? License-wise, there shouldn't be any problems to put permissive code inside a copyleft project (except maybe politics).
- twoodfin 14y ago
  Sure: Generating good diagnostics requires a large quantity of infrastructure, much of which is inherent to the compiler's design and not something readily ported piecemeal. That's not to say one compiler won't learn and benefit from changes in the other, but reimplementing features in a very different design is more than a simple "copy".

npsimons 14y ago

More than a few years ago, it was very easy to imagine a breakout compiler getting developers excited. I think it was call "egcs" or somesuch . . . Joking aside, I'm glad for the competition, and for the options. It's always nice to have another automated way to audit code: throw another compiler with maximum warnings at it.

protomyth 14y ago
The most interesting thing for me is the library approach to the compiler. I wonder if it would benefit some other open source languages to restructure this way. It is a nice idea to be able to use the same compiler libraries in other tooling.
- npsimons 14y ago
  While the separation of concerns in LLVM is laudable, I think that too many developers aren't even aware of some of the nice features in GCC. I was pleasantly surprised to find that Go support is now an option in building GCC, and I wouldn't be surprised if its fast adoption was in no small part due to the modularity of GCC (I've unfortunately not had the time to track development of GCC or LLVM for years). It still surprises me how many C/C++ developers don't know about _FORTIFY_SOURCE, -fstack-protector, or even -fmudflap. Consider also that coverage and profiling are builtin, and GCC offers a nice set of tools for professional software development. They're just not well advertised. I'm grateful for LLVM, but I wonder if some of the excitement over it is not just hype and it being the new hotness. EDIT: Can't believe I used "it's" instead of "its".
  - protomyth 14y ago
    I guess my question would be "Can I use the same parser that GCC uses in my tool?". I am most interested in that aspect of clang.
    - DannyBee 14y ago
      This is, in large part, something the FSF did not want to happen without the app being GPLv3. The other interesting thing is that this is only really an issue due to difficulty in properly parsing/semantically analyzing languages like C++. For languages like Java, it simply isn't necessary, or in some cases, desirable.
      - protomyth 14y ago
        "For languages like Java, it simply isn't necessary, or in some cases, desirable." Why would it not be desirable? Also, if I have an idea for a great tool, why should I have to write my own parser? I have more faith the actual compiler will have bugs fixed quicker in this regard.
        mjn 14y ago
        If your goal is non-compiler analysis, like refactoring or verification, it's often more flexible to use a framework specifically designed to analyze source code and give you a nice AST with various options, rather than pulling the parser out of a compiler front-end. For languages with reasonably simple grammar there are usually one or more such packages, usually pretty well debugged. For example, for Java you could use http://spoon.gforge.inria.fr/ http://spoon.gforge.inria.fr/
        npsimons 14y ago
        As a counter-example/argument, CEDET/Semantic (http://cedet.sourceforge.net/semantic.shtml http://cedet.sourceforge.net/semantic.shtml) will use Clang/LLVM and/or GCC if you tell it to. It only makes sense, if someone has already gone to the trouble of not only writing a full up parser and lexer for your language, but also exposing things through modularization, you might as well use it.
- drothlis 14y ago
  http://docs.python.org/2/library/ast.html http://golang.org/pkg/go/parser/ (See also gofmt: http://golang.org/cmd/gofmt/ and gofix: http://golang.org/cmd/fix/ )
ajross 14y ago
To be fair: egcs was a fork. It was a group of GCC people deciding that they wanted to work on the GCC code outside the control of the GCC project administration. And as it happened they were better at it and the FSF essentially took egcs back into the fold by handing over control of "GCC" to the forked project. LLVM/clang is a rather different thing, for both good and bad reasons.

pwg 14y ago

In a way there is some aspect of history repeating itself. The current compiler known as "GCC" is a direct descendant of an earlier GCC fork named EGCS: http://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fork http://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fo... So GCC was already "unseated" once, the difference being by a direct descendant instead of by a fully different compiler.

pjmlp 14y ago
Oh man, memories of having gcc and egcs both installed with different support levels for C++ :(
- frozenport 14y ago
  And also running Gentoo unstable branch with that nonsense.

DannyBee 14y ago

It depends on what you mean by a few years ago. Even 5-6 years ago, it was clear to a bunch of GCC devs this was going to be the result :) The need and desire was very clear, and it was clear LLVM would meet that.

pjmlp 14y ago

What I find very positive about clang/llvm is: - Everyone now seems to be using LLVM for language prototyping instead of JVM/.NET, clearly positive for native compilation and to show people without compiler knowledge that managed != VM - The compiler as a library implementation of clang allows C, C++ and Objective-C to enjoy tooling support similar to JVM and .NET languages - As someone with a sweet spot for the strong typing found in the Pascal family, the integrated static analysis are just great

hga 14y ago
Does it have a good story for doing precise GC? When I looked at it some time ago, it appeared that I'd have to understand and write a lot of C++ code ... which I very much don't want to do.
- pcwalton 14y ago
  No, LLVM's support for precise GC is not great. You can do it, but you have to spill all registers that might contain pointers across all calls, which is a significant performance hit. (Note that GCC is the same way though, as I understand it.) In my opinion, you're usually better off just doing conservative-on-the-stack GC if you're using LLVM. (This is what Rust does.) The basic problem is that LLVM loses the distinction between pointers and integers as soon as it drops into SelectionDAG and later passes. Fixing this would be a lot of work.
  - billwashere 14y ago
    Another cool LLVM based project that has Garbage Collection is the Epoch Programming Language[0] uses a similar approach [1]. Original reddit submission here [2]. [0] https://code.google.com/p/epoch-language/ https://code.google.com/p/epoch-language/ [1] https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme https://code.google.com/p/epoch-language/wiki/GarbageCollect... [2] http://www.reddit.com/r/programming/comments/1c5jz6/realistic_garbage_collection_on_top_of_llvm_epoch/ http://www.reddit.com/r/programming/comments/1c5jz6/realisti...
  - jules 14y ago

jjtheblunt 14y ago

What is an example advantage of gcc? (old parallelizing compiler person asking, but not working on such for years, randomly)

stephencanon 14y ago
OpenMP support.
- jjtheblunt 14y ago
  Thanks.
- emaste 14y ago
  Intel has recently released a permissively-licensed OpenMP runtime (http://www.openmprtl.org/ http://www.openmprtl.org/) though, and Intel's compiler team is working on OpenMP support (http://software.intel.com/en-us/forums/topic/391189 http://software.intel.com/en-us/forums/topic/391189, slides at http://llvm.org/devmtg/2013-04/bokhanko-bataev-slides.pdf http://llvm.org/devmtg/2013-04/bokhanko-bataev-slides.pdf) in Clang/LLVM using it. I suspect it won't be long before there's parity on this point.

belorn 14y ago

Is there any strong technical reasons why GCC can't just copy any useful features from Clang such as the improved error messages and put that into GCC? License-wise, there shouldn't be any problems to put permissive code inside a copyleft project (except maybe politics).

twoodfin 14y ago
Sure: Generating good diagnostics requires a large quantity of infrastructure, much of which is inherent to the compiler's design and not something readily ported piecemeal. That's not to say one compiler won't learn and benefit from changes in the other, but reimplementing features in a very different design is more than a simple "copy".