Hacker News Reader

Comment by noobermin | Hacker News Reader

I'm not sure if this will stoke a flamewar, because I've never seen a discussion here on this (might just be hanging around different articles). Is there any technical reason to prefer clang over gcc other than ideological reasons? I get the modular nature of llvm is useful, but is the android NDK using this feature?

Quick google search shows clang lagging gcc in all but one test[0] at least on Intel Broadwell. Again, what is the benefit other than permissiveness of the license?

[0] http://www.phoronix.com/scan.php?page=article&item=clang-gcc... This is almost a year old, though

View on HN

I don't know much about Android NDK, but in general, people use clang because:

- Clear and readable diagnostics -- especially useful when debugging nasty C++ template stuff where the type signature is a page long. (GCC is catching up in this area)

- Modular design -- if an IDE wants to have syntax highlighting or an Xcode/Eclipse/IntelliJ like "fix it" feature, they can use the clang frontend to parse the code. Also, GCC's "big ball of mud" design (iirc they do some optimizations like constant folding in the parser) makes it harder to hack on unless you're already pretty familiar with the codebase.

- Less hostile community -- people have tried to clean up GCC but their patches were rejected (see the RMS email link below)

- Helps you with standards compliance -- clang will still compile code with compiler-specific extensions but it has an option to output a warning. There are some codebases that have come to rely on these behaviors so clang's warnings can help make sure you don't end up tied to one specific compiler.

- Personally, I like AddressSanitizer (ASan). It does similar checks as Valgrind, but using compile-time instrumentation -- just pass in an additional flag. Gets rid of a dependency.

in contrast, i recall pre-egcs gcc being very easy to hack and port.

egcs, on the other hand, was a much needed kick in performance and features of gcc, but had the negative of making it harder to maintain and understand.

lcc was a good example of moving back into the simple compiler design, but it seemed to have stayed more in academia.

FWIW, GCC has ASan too. [0] I'm not sure how it compares to the LLVM implementation, I've only tried LLVM's (with good results).

Having said that, I hack on LLVM daily and would not relish having to use GCC to the same effect. LLVM really does shine when used as a library!

[0]: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

ASan and UBSan are the same in the two; both the GCC and clang instrumentation shims were contributed by Google, and the resulting instrumentation is the same.

Here's one incredibly awesome feature of Clang: Windows support (thanks to Google, actually).

No Cygwin/msys required -- it implements the Windows calling conventions, exception handling, etc. You can link modules compiled with Clang using the Microsoft linker.

https://www.youtube.com/watch?v=dr0eY9c23i8

mingw (now mingw64) has been doing that for ages as well -- I'm too busy to check right now, but I suspect since before clang supported windows.

gcc has had support for every operating system under the sun at one point or another - I fondly remember using the DJDelorie version for DOS+Extender, and if I'm not mistaken, there was also a release that could do WIN32 on Windows 95 from delorie.

Clang had a number of benefits over GCC such as better error messages and integration points for IDEs (syntax checking/etc) which caused Apple to switch to it (on top of licensing). It may have been faster, not sure, but the internals were supposed to be MUCH cleaner and easier to work with.

I know a number of these issues have been improved/fixed in GCC over the last few years. Outside friendliness to internal tinkering and non-GPL software I'm not sure if one as serious technical superiority. I believe clang is written in C++ instead of C, for whatever that's worth.

GCC has always had a much bigger set of supported platforms and processors.

> not sure, but the internals were supposed to be MUCH cleaner and easier to work with.

I've bookmarked this bit of GCC code for my own amusement - an anecdote about the quality of GCC's codebase:

https://github.com/gcc-mirror/gcc/blob/7057506456ba18f080679...

For development, having full access to the AST at will is a definite good reason. Having such allows you to analyze your code as you're writing it in much more intimate ways, allowing for better refactoring tools, better error analysis, better variable completion, etc. Additionally, because of the modular format of clang, pretty much every build is a cross compiler. You don't need to rebuild clang to get support for arm and x86, for example. There's even targets for GPUs, so you can use the same toolset top to bottom much more effectively.

Better security features for one. Clang supports SafeStack and Control Flow Integrity. SafeStack is much more performant than gcc's stack protectors, and gcc offers no equivalent of CFI.

So, I'm not familiar with all of the CFI protections available in clang, but is full CFI actually implemented in CLANG?

Especially with C/C++, there are a lot of potential attack vectors that would need to be closed (stack smashing, ROP, Vtable corruption). From a laymans perspective, some of these need full memory corruption protection.

Any references would be appreciated. The last time I had to adress CFI in C, static analysis (with greater precision than CLANG had) was involved.

Clang's CFI implementation is documented here: http://clang.llvm.org/docs/ControlFlowIntegrity.html

It's not a full CFI, but my understanding is that it does completely prevent vtable corruption with ~5% overhead (measured for Chromium).

It's an entirely subjective argument - but I've felt the warning and error messages from clang were so much better than those from GCC that developing under clang became a no-brainer.

Also, I believe ASAN started with clang.

In addition to what other people have said, Clang and LLVM are improving at a much faster rate than GCC.

So while they may still be lagging in some areas, I'm confident they'll get ahead of GCC in those areas long before GCC catches up in the areas where it's behind.

The permissive license of LLVM means that you can build it into tools. So in that one case, the political difference of the license does lead to a technical difference.

Reply on news.ycombinator.com