3 ms·

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 s

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.
    - DannyBee 14y ago
      It wouldn't be desirable in a lot of cases for the reason the other person mentioned. I don't believe you should have to write your own parser mind you, just that your compiler's parser may not be the one you want. In general, most languages are stable enough that you don't really get parsing/semantics bugs, so you wouldn't really need to worry about your last concern. C++ is simply so complicated that the implementations end up with a bugs due to necessary complexity of implementation, but this is not generally true of languages.
- npsimons 14y ago
  Semantic in CEDET (http://cedet.sourceforge.net/semantic.shtml http://cedet.sourceforge.net/semantic.shtml) will do this with both GCC and Clang/LLVM.
- belorn 14y ago
  If you use code from GCC and distribute the combined work, then you must adhere to the license of GCC. With CLANG, same is true, but the license requirementa are fewer.
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).

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.
  - DannyBee 14y ago
    It wouldn't be desirable in a lot of cases for the reason the other person mentioned. I don't believe you should have to write your own parser mind you, just that your compiler's parser may not be the one you want. In general, most languages are stable enough that you don't really get parsing/semantics bugs, so you wouldn't really need to worry about your last concern. C++ is simply so complicated that the implementations end up with a bugs due to necessary complexity of implementation, but this is not generally true of languages.
npsimons 14y ago
Semantic in CEDET (http://cedet.sourceforge.net/semantic.shtml http://cedet.sourceforge.net/semantic.shtml) will do this with both GCC and Clang/LLVM.
belorn 14y ago
If you use code from GCC and distribute the combined work, then you must adhere to the license of GCC. With CLANG, same is true, but the license requirementa are fewer.

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