
Why IBM Now Views LLVM As Being Critical Software - protomyth
http://www.phoronix.com/scan.php?page=news_item&px=MTM2NjU
======
jeffdavis
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
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
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
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
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
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
"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
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/>

~~~
npsimons
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.

~~~
DannyBee
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.

------
filereaper
While Clang/LLVM is cool, this is more of a pure business decision.

IBM supports multiple compiler toolchains: XL C/C++/FORTRAN, GCC, Java, COBOL,
etc...

So, when a customer comes by with a codebase and wants to run it on their
System x/System p/System z big iron, IBM's response needs to be a simple "Yes"
when it comes to support.

Customer A has used XL since the epoch of computing, cool, that's supported.

Customer B has codebase tuned and littered with GCC attributes, cool, that's
supported as well.

Customer C wants Clang/LLVM because devs find it easier to debug and it's
growing in features, cool, that will be supported as well.

