- Licence<p>- Not designed to be difficult to extend<p>Everything else is basically irrelevant because as Clang has aged it's both slowed down and reached parity in both compile and execution speed. Phoronix even have GCC <i>faster</i> than Clang at building the Linux Kernel, even in an (according to a comment) biased sample where GCC wasn't built with lto enabled. GCC also (last time I tried) does better debug info.<p>LLVM is <i>much</i> easier to hack on, though, although some parts are more similar than you might expect.<p><a href="https://www.phoronix.com/scan.php?page=news_item&px=GCC-Faster-Kernel-Builds-Clang" rel="nofollow">https://www.phoronix.com/scan.php?page=news_item&px=GCC-Fast...</a><p>You should try and fettle with both to see what works best for your project.
I imagine this page's creative process to be something like:<p>- Okay, we need to think of some reasons besides "It's not GPLv3".<p>- In fact, let's list that one last so it looks like an afterthought that doesn't concern us so much.<p>- Hmm, no, too conspicuous. Make it next-to-last.
This is a cool repository! fairly old, as others have noted.<p>There's a directory [1] containing some "historical notes" written by the creators of llvm: Chris Lattner and Vikram Adve. One of them is the original clang readme [2].<p>[1]: <a href="https://opensource.apple.com/source/clang/clang-800.0.42.1/src/docs/HistoricalNotes/" rel="nofollow">https://opensource.apple.com/source/clang/clang-800.0.42.1/s...</a><p>[2]: <a href="https://opensource.apple.com/source/clang/clang-800.0.42.1/src/docs/HistoricalNotes/2007-OriginalClangReadme.txt.auto.html" rel="nofollow">https://opensource.apple.com/source/clang/clang-800.0.42.1/s...</a>
> GCC does not require a C++ compiler to build it
> GCC front-ends are very mature and already support C++. clang's support for C++ is nowhere near what GCC supports.<p>These things were true when Apple first went with Clang, and this document must date from that time.<p>GCC is now implemented in C++, and Clang’s C++ support is excellent. The only issue I have with my c++17 code in Clang is I can’t yet rely on recursive template parameter pack deduction.
> Clang does not implicitly simplify code as it parses it like GCC does. Doing so causes many problems for source analysis tools: as one simple example, if you write "x-x" in your source code, the GCC AST will contain "0", with no mention of 'x'. This is extremely bad for a refactoring tool that wants to rename 'x'.<p>Can someone explain this Clang “pro”? If a refactoring tool wants to rename “x”, it does it to the <i>source</i>, not the AST, no? And if “x-x” is turned into 0 by the parser, why does it matter? Assuming “x” isn’t volatile, “x-x” is <i>indeed</i> 0!
Can't talk about superiority of one compared to the other without viewing the landscape of the develop, it needs to run fast, be easy to debug, compile fast. There are trade offs for all. Most serious devs likey run several ide and build chains, ea h offering its own value. For example if you want clean template debugging clang lldb is pretty nice
Slight offtopic: anyone else annoyed by the darwins crappy support for static linking and general <i>extreme</i> lack of documentation? E.g lack of -Bstatic option and similar?
TL;DR<p>"GCC is licensed under the GPL license. clang uses a BSD license, which allows it to be used by projects that do not themselves want to be GPL."<p>For example, Apple can keep their internal backends (GPU, some ARMv8 details) proprietary.