Hacker News Reader

Comment by npsimons | Hacker News Reader

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

View on HN

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

The official reason as mentioned in Go's 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

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

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.

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.

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

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/

As a counter-example/argument, CEDET/Semantic (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.

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.

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.

Semantic in CEDET (http://cedet.sourceforge.net/semantic.shtml) will do this with both GCC and Clang/LLVM.

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.

Reply on news.ycombinator.com