Tangential: I think many platforms that GCC supports and the kind of optimisation GCC provides might make it a superior choice for projects. For those developers its exciting. Also if an existing project is using it for a long-time and has not intentions of switching to Clang, for them too this would be interesting.
My project uses g++ but I’ve been using a clang static-analysis step in my CI pipeline for a while now.
Compiling with clang is much, much slower but it finds interesting errors sometimes. I only had to ifdef out one code section that it couldn’t understand (something about indexing an array with a constexpr function returning an enum class from a template parameter).
It depends on the project, but this one and another project I made work are both 100k lines of C++ and took half a day to setup. It was worth it imo.
Interesting that your build times are slower with clang. I've found on most of my projects clang is roughly 30% faster to compile in debug, but release I haven't seen a huge difference between the two.
Static analysis is a lot slower but regular clang++ is also significantly slower than g++, like a 4-5 minute build time vs 2:30 on g++.
It might have something to do with a heavy usage of templates in a few files, I don't know.
Clang's autovectorization is better in a few functions I disassembled but otherwise the generated code doesn't benchmark any faster, it's better in some places, worse in others.
Clang has it although I've personally never tried it due to the horrible rigamarole of setting it up.
In GCC it's a compiler flag. In LLVM it's a convoluted process automated by either an irritating perl/python script (The python one isn't included by default for some reason despite being far more common these days) or AN ENTIRE WEB SERVER TO OUTPUT TEXT (Which thankfully isn't included by default).
I'm sure you could set it up in make but since my projects aren't large scale enough to really need it I can't be bothered, even if it's one of those things you'll probably only need to write once and can just copy and paste ad-infinitum.
Lest other people get the wrong impression from someone who's admitted not even trying it, running Clang's static analyzer is as simple as switching cc with scan-build. You can even drive it from clang-tidy. No Perl or Python setup in my experience.
Though scan-build is usually the simpler option, clang itself does have an --analyze flag which writes analysis results in various formats, including the same html reports that scan-build would generate. But to see this on standard out
clang --analyze --analyzer-output text ...
Will print the entire analysis tree in the same format as regular diagnostics.
The only problem is the CTU mess if you're analyzing more than one file, thus the aforementioned tools' necessity.
Hopefully in a future version the kinks are ironed out and we can just use the flag without any hassle. It's like if we needed to still manually link our files with ld before compiling them instead of clang auto doing it.
Yep! Thanks for pointing out the perl script I mentioned. You appear to have completely ignored the rest of my post on them leaving important functionality to third party scripting languages.
Yes, to highlight that this "horrible rigmarole" and "irritation" you describe is entirely on the basis of there being a Perl script involved. Something I suspect the majority would overlook without even really noticing.