4 ms·

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 asid

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.
        DannyBee 14y ago
        Again, the argument i've made is that this is only because C/C++ are so difficult to otherwise parse and auto-complete. Can you find a java example (for example :P)? AFAIK, all the java IDE's use their own incremental parsers and completers.
  - kkowalczyk 14y ago
    The most likely reason gcc was used was that Ian Taylor, the guy who is part of Google's core team and wrote gccgo, was already familiar with gcc by virtue of being long-time gcc developer. There already is a project to build a go compiler on top of llvm (https://github.com/axw/llgo https://github.com/axw/llgo).
    - wting 14y ago
      The official reason as mentioned in Go's FAQ (http://golang.org/doc/faq http://golang.org/doc/faq): > We also considered using LLVM for gc but we felt it was too large and slow to meet our performance goals. Does this mean compilation speed, performance speed, or both? Or is this a hand-wavy excuse to use gcc instead due to Ian's expertise? That being said, there is a project that builds Go on top of LLVM: https://github.com/axw/llgo https://github.com/axw/llgo
      - gillianseed 14y ago
        >Does this mean compilation speed, performance speed, or both? Or is this a hand-wavy excuse to use gcc instead due to Ian's expertise? IIRC that remark related to using LLVM or GCC as the backends for the Go compiler, basically they found both backends to be too large and slow for their liking so they wrote their own full compiler from scratch. I believe the GccGo project is mainly about leveraging all the architectures which GCC supports, many of which Go isn't ported to and possibly won't be ported to (as in maintained by the Go developers).
- 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.

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.
        DannyBee 14y ago
        Again, the argument i've made is that this is only because C/C++ are so difficult to otherwise parse and auto-complete. Can you find a java example (for example :P)? AFAIK, all the java IDE's use their own incremental parsers and completers.
- kkowalczyk 14y ago
  The most likely reason gcc was used was that Ian Taylor, the guy who is part of Google's core team and wrote gccgo, was already familiar with gcc by virtue of being long-time gcc developer. There already is a project to build a go compiler on top of llvm (https://github.com/axw/llgo https://github.com/axw/llgo).
  - wting 14y ago
    The official reason as mentioned in Go's FAQ (http://golang.org/doc/faq http://golang.org/doc/faq): > We also considered using LLVM for gc but we felt it was too large and slow to meet our performance goals. Does this mean compilation speed, performance speed, or both? Or is this a hand-wavy excuse to use gcc instead due to Ian's expertise? That being said, there is a project that builds Go on top of LLVM: https://github.com/axw/llgo https://github.com/axw/llgo
    - gillianseed 14y ago
      >Does this mean compilation speed, performance speed, or both? Or is this a hand-wavy excuse to use gcc instead due to Ian's expertise? IIRC that remark related to using LLVM or GCC as the backends for the Go compiler, basically they found both backends to be too large and slow for their liking so they wrote their own full compiler from scratch. I believe the GccGo project is mainly about leveraging all the architectures which GCC supports, many of which Go isn't ported to and possibly won't be ported to (as in maintained by the Go developers).
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.