User: Password:
|
|
Subscribe / Log in / New account

Distributions looking at LLVM

Distributions looking at LLVM

Posted Mar 22, 2012 13:44 UTC (Thu) by tshow (subscriber, #6411)
Parent article: Distributions looking at LLVM

I've been using XCode for a while now (doing iOS versions of our games...), and I wouldn't exactly describe the switch from gcc to llvm as a positive one. Granted, some of the problem is that XCode wasn't very good to start with and gets worse with every version, but some of it is definitely llvm as well.

One of the things I keep hearing about llvm is that the error reporting is supposed to be top notch; it's supposed to be really good at pinpointing the actual error instead of pointing to wherever the compiler finally gave up.

Sadly, in practice, llvm is the worst compiler I've worked with for errors since... well, the early 90s, at least. I've had a typo in a variable name in a single location generate a cascade of hundreds of errors, *none* of which referenced the actual syntax error. Leave out a semicolon by accident and you'll see an error cascade. Put 1,0f instead of 1.0f, error cascade.

Somehow none of these trip up gcc at all.

Debugging was a lot more reliable under gcc as well. Since the llvm switch, two times out of three trying to watch a variable brings XCode down in flames.

Code generation seems no better (our games take the same amount of time to build, roughly, and we've seen no measurable performance difference in the games), and we haven't noticed much else different except for the occasional llvm crash.

Perhaps it's better when it isn't running on OSX, but personally I'm filing llvm under "lots of potential, needs to mature".


(Log in to post comments)

Distributions looking at LLVM

Posted Mar 22, 2012 21:34 UTC (Thu) by Yorick (subscriber, #19241) [Link]

My own experience is quite the opposite - Clang's diagnostics are both more useful and precise, and there are also more warnings about potential mistakes. Perhaps you used an old version?

I maintain a medium-sized proprietary application, a few million lines of C and C++ code. We use GCC and are mainly happy with it, but do build with Clang from time to time, just to see if it catches something that GCC didn't - and it often does. I also sometimes use Clang for particularly messy C++ work because of its clearer diagnostics.

Interestingly, Clang builds our code base slower than GCC. This is most likely because our compile times are dominated by a few very large (>100000 lines) machine-generated C files with very large functions, and apparently Clang doesn't handle this quite as well as GCC. For more reasonably-sized files, Clang is faster.

The quality of the generated code for our purposes (branchy integer code, very little FP, nothing vectorisable) is comparable between the compilers - the difference is usually not significant.

Distributions looking at LLVM

Posted Mar 23, 2012 8:54 UTC (Fri) by khim (subscriber, #9252) [Link]

We use GCC and are mainly happy with it, but do build with Clang from time to time, just to see if it catches something that GCC didn't - and it often does.

This is biased selection. Both GCC and Clang have cases where one compiler produces garbage and another gives you nice and clean message, but if you if only run Clang when GCC produced garbage then you are missing cases where GCC gives clean messages and Clang blows up.

Interestingly, Clang builds our code base slower than GCC.

Again: YMMV. Often Clang is faster but in our codebase there are file which GCC compiles in 50seconds with full optimization while Clang needs 9 minutes - that's 10x slowdown (MSVC is two times worse then Clang).

This is most likely because our compile times are dominated by a few very large (>100000 lines) machine-generated C files with very large functions, and apparently Clang doesn't handle this quite as well as GCC.

LOL. Our case is similar, too. Clang and GCC produce code of similar speed and size in the end even if one needs 10x more time then the other.

Distributions looking at LLVM

Posted Mar 23, 2012 14:57 UTC (Fri) by Yorick (subscriber, #19241) [Link]

This is biased selection. Both GCC and Clang have cases where one compiler produces garbage and another gives you nice and clean message, but if you if only run Clang when GCC produced garbage then you are missing cases where GCC gives clean messages and Clang blows up.

Certainly — swap GCC and Clang, and my statement would have been equally valid. I'm happy that we have not just one but two free compilers of very high quality, that implement most of the same language extensions and even take the same command-line options.

We do run both GCC and Clang with -Wall -Werror, by the way, forcing ourselves to fix even minor complaints from either compiler. This has proven very effective.

Distributions looking at LLVM

Posted Mar 23, 2012 19:33 UTC (Fri) by oak (guest, #2786) [Link]

It's nice to hear that Clang has significantly improved!

I've used GCC v4.4 and Clang v1.1 / LLVM v2.7 in Debian stable to compile largish C programs and with these old versions GCC provides much superior detection of issues (while the errors Clang reports are more readable).

Which versions of GCC and Clang/LLVM you were using?

Btw. I would recommend adding quite a few extra warning options to GCC & Clang as -Wall misses quite a few things that can go wrong. For example: -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wwrite-strings -Wformat-security -Wshadow.

Distributions looking at LLVM

Posted Mar 30, 2012 16:35 UTC (Fri) by mlopezibanez (guest, #66088) [Link]

My own experience is quite the opposite - Clang's diagnostics are both more useful and precise, and there are also more warnings about potential mistakes. Perhaps you used an old version?
I would encourage you and everybody else to report bugs for GCC diagnostics that you find to be worse than Clang's. GCC diagnostics have improved a LOT in the last few releases. In the order of hundreds of patches and probably close to a hundred bugs fixed per release.

Fortunately, many issues are quite trivial, and they can be fixed by changing one line. Unfortunately, the entry barrier for submitting a one-line patch is so huge that very few external contributors ever suggest such patches.

Unfortunately x 2, some issues are not so easy to solve and there are some known limitations of GCC diagnostics that makes it look worse than Clang. Overcoming these limitations does not seem to be a priority to GCC maintainers. It is true that despite the bitching in blogs and forums about how awful GCC diagnostics are, the developers don't actually see that many reports about it. But I think if enough people reported the problems that they find, something will eventually be done about it.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds