We restrict the discussion to very specific objective points to avoid controversy where possible. Also, software is infinitely mutable, so we don't talk about little details that can be fixed with a reasonable amount of effort: we'll talk about issues that are difficult to fix for architectural or political reasons. The goal of this list is to describe how differences in goals lead to different strengths and weaknesses, not to make some compiler look bad.
This will hopefully help you to evaluate whether using clang is a good idea for your personal goals. Because we don't know specifically what you want to do, we describe the features of these compilers in terms of our goals: if you are only interested in static analysis, you may not care that something lacks codegen support, for example. Please email cfe-dev if you think we should add another compiler to this list or if you think some characterization is unfair here.
Note that there is a fork of Elsa known as "Pork". It addresses some of these shortcomings by loosely integrating a preprocessor. This allows it to map from a source location in the AST to the original position before preprocessing, providing it better support for static analysis and refactoring. Note that Pork is in stasis now too. Clang vs Other Open Source Compilers Building an entirely new compiler front-end is a big task, and it isn't always clear to people why we decided to do this.
GCC is popular and widely adopted. Pro's of clang vs GCC: The Clang ASTs and design are intended to be easily understandable by anyone who is familiar with the languages involved and who has a basic understanding of how a compiler works. GCC has a very old codebase which presents a steep learning curve to new developers. Clang is designed as an API from its inception, allowing it to be reused by source analysis tools, refactoring, IDEs etc as well as for code generation.
GCC is built as a monolithic static compiler, which makes it extremely difficult to use as an API and integrate into other tools. Further, its historic design and current policy makes it difficult to decouple the front-end from the rest of the compiler.
In release 50 the DragonFly people started work on pulling it into base. NetBSD has included clang in base but as far as I know does not yet build with it by default on any architecture. But in my defense the situation, at least originally, was more political than technical at least as far as FreeBSD was concerned, I don't follow the other BSDs too closely. As a result they were at the forefront to port the system to clang since they were stuck with an obsolete GPLv2 GCC version.
License mostly. This is what I do. I use clang for everything except the final release. I get clang's speed and superior error messages while I'm editing code, and I get the very slightly, but measurably faster code generated by GCC. HelloNurse on July 26, parent prev next [—].
On the other hand, the effort of learning clang options, error messages and paths in order to have two compilers available can wait indefinitely until I really need a second opinion about some compilation error; so far it hasn't happened. Then it's trivial to switch compilers with one argument. This feature is a result of Google's years-long support of both GCC and clang for its own build, test, and release. HelloNurse on July 26, root parent next [—].
Sorry, I lost you at "bazel". Do you believe constructing clang command lines in addition to gcc command lines is harder than setting up a particularly complex build tool like Bazel? Bazel comes with an installer package that you click and run. I didn't find it that complicated.
Whether the developers gave up on the Mingw64 GCC and Clang toolchains or it's a documentation mistake, this statement places Bazel support for Windows in the "don't touch with a 10' pole" category. But my point was that adopting Bazel is obviously far more complex than adapting existing build scripts and build script generators for Make, Cmake, Ninja etc to use Clang.
Options are mostly the same. You can easily switch out the two compilers in most build systems. This seems like it would be a nightmare to deal with if things ever went wrong. Is this actually a viable option? Not a big deal. I had a similar workflow, except icc for release, which still outperforms gcc on certain types of codebases. And of course the licensing makes a huge difference.
So in terms of mindshare among people who are doing compilers, it's kind of a no-brainer. IshKebab on July 26, prev next [—]. GCC is still important, but yeah Clang is definitely more popular and gaining popularity.
I don't think the performance difference between them is significant, but Clang is much nicer if you want to use it as a library, add a new backend, etc. Basically if you want to do anything other than run it from the command line. Oh also, Clang does cross-compilation in a not totally insane way. I wouldn't be surprised if GCC is abandoned eventually, but it will be at least 10 years. Let's hope not. The healthy competition between the two projects has been a huge boon for the OSS community.
A free compiler under a free license is a pretty central project for them. Besides that, making predictions 10 years out into the future of software seems meaningless.
Saying "this thing might still be around in like 2 decades, or not" is If anything, GCC development has gotten far more active and improved greatly in the past few years, with consistently high quality releases, each bringing in major features, and adopting work from Clang, and bringing in their own unique work. It would seem each of these projects has livened up quite a lot over time and are offering higher quality than they ever have before.
What reason do you have to believe it will be completely abandoned? Just because there's an alternative available? That never happened with Linux, either I think it really does boil down to the license: Apple absolutely hate copyleft, so they poured money into Clang. And I really don't think that copyleft would hurt Apple: what compiler technology do they want to keep proprietary?
Apple started heavily investing in clang and friends because they wanted a compiler suite that was more modular than gcc and that could be used as a library in other things.
They wanted to use the compiler's parser as a library in Xcode to handle things like syntax highlighting. Gcc could not do these things as it was at the time. The different parts were tightly coupled in ways to make it hard to separate things out. People had proposed making it more modular but the gcc devs rejected them, with RMS making it clear that the design was the way it was in order to make it harder for proprietary programs to have ways to use gcc's parts.
Apple could have forked gcc and changed it to be more modular, but that would have required a lot of changes and a lot of work, and since it would not be accepted upstream they would probably have to do a lot of work every time there was a significant gcc update. It made much more sense in every way for them to go with clang and LLVM, because those were designed to allow the kind of modular, library use that Apple wanted. GCC progress was pretty slow before the rise of clang.
Clang introduced many features that werent really on the radar of GCC, like better formatting of error messages, tight integration of tools like thread and address sanitizer, and in some areas even more and better warnings.
Meanwhile - at least for a short period - gcc was on this optimization fad where they'd just take any occurrence of UB as a reason to silently eliminate chunks of code and render the whole program useless in some cases.
With 4. The GCC folks always argued that doing so is legal by the standard, but eventually there was enough backlash that the worst instances of such aggressive optimizations were removed. I'm glad GCC optimizes well and takes advantage of language definitions specifically Fortran's while being more reliable than ifort which gets lionized for optimization.
That's not the point. Of course you should write proper code, not do goofy things with pointers etc. Find centralized, trusted content and collaborate around the technologies you use most. Connect and share knowledge within a single location that is structured and easy to search. GCC is a big bag of software. LLVM is, perhaps, two things then. Despite the name, LLVM is not a Virtual Machine in the traditional sense - it is a computation model and representation that lends itself well to the task of manipulating code.
It can be used for performing static analysis on code "does this code ever accidentally use uninitialized memory? One example is that GCC's frontends perform some optimizations during parsing, so it is not possible to always get a perfect representation of the code-as-typed, for eg, reporting errors and performing squiggle-line syntax highlighting, because some information might have been lost.
As I understand it, Clang preserves the unoptimized parsed syntax, making it possible for 3rd party tools to use its output and equate transformations back to the original text, most notably, Clang's error messages are much more helpful because they can highlight the exact part of the line that is in question. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Ask Question. Asked 7 years, 4 months ago.
Active 4 months ago. Viewed 24k times. Is there an advantage to using clang?
0コメント