I think the main differentiators for clang were more readable error messages than the mess GCC had (and still has), and faster compilation (here it lost a bit of its advantage over time). I haven't heard of anyone praising it over GCC based on standard compliance.

That said, when I explore weird edge cases in how differently Clang and GCC parse source code, and how differently they optimise it, in my experience Clang is still the more logical one, whenever there is a disparity, whereas the way GCC parses code and what code it produces is sometimes completely baffling (and that's not just optimisation stuff - without any optimisations enabled I encountered miscompilations a lot more with GCC than Clang).

I also consider C++ a language for mostly old projects. I start new ones in other languages and don't consider repeated rewrites every two standards, because the "modern c++" crowd found a new way to initialise variables, to be a good investment of my time.

> I haven't heard of anyone praising it over GCC based on standard compliance.

Back in the day (C++0x era), it was near bleeding edge. Clang had all the proposed 0x features ready to go before C++11 was released.

It took a while for GCC to get all the C++11 features after the release.

> Clang had all the proposed 0x features ready to go before C++11 was released.

Except garbage collection, of course.

> I start new ones in other languages and don't consider repeated rewrites every two standards, because the "modern c++" crowd found a new way to initialise variables, to be a good investment of my time.

Same here, but I update my new code as I go if there is a better/safer way to do it that does not impact in any bad way my codebase.

You don’t have to rewrite anything. C++ keeps backward compatibility. You don’t have to make it sound like it’s the case, and you don’t have to shame the "modern c++ crowd" over that false claim. That’s just uncalled for, unconstructive and partisan discourse. I expect better from HN.

Did you see the original post? Lots of code changes were required for Chrome. That’s not backwards compatible.

It’s 99.9% backward compatible. The comment makes it sound like it’s a huge pain every 2 years, as if it was the "python 2 to 3" level of pain.

I went through a lot of these new versions, starting with c++11, and can’t remember one time I had to change anything to my code based, appart from silencing deprecation warnings for unicode stuff.

Now I get that chromium-like code bases are huge and that the 0.1% of backward incompatibility is still a pain. Now, with that level of hugeness of code bases, maintaining it when the language evolves is going to be a pain. C++ has been very careful with backward compat, breaking very few things, compared to other languages. So these criticisms really are uncalled for to me. Sounds like good ol c++ bashing trying to sound wise.

I felt the comment wasn’t fair and wasn’t an honest criticism. Sorry for my angry comment. We live in rough times.

I've done several Python 2->3 transitions, and the amount of effort looks to be in the same order of magnitude described in the post.

This has no relation to Clang's permissive license. The problem here is generally that nobody has implemented the necessary support, not that they have implemented support in their private forks but did not bother to upstream it. A GPL-style license doesn't magically force contributors to start working on a particular feature.

Google at least is one of the largest contributors to the LLVM project -- it's just that their contributions don't tend to focus on Clang frontend work.

Anymore. Google used to contribute quite a lot to libc++ especially, but have found that the language is going in a direction that doesn’t meet its needs.

Not sure why Google would continue to contribute under those circumstances.

The thing vendors care about more than anything is making upstream work supported.

Google isn't even complaining about things, this is a very dry technical document about their experience, for an amount of work they certainly expected and were possibly even pleasantly surprised about.

These sorts of things are routine in massive code bases

Why is it ironic?

gcc is better than clang on every metric. Sorry, it's the facts. ¯\_(ツ)_/¯

Whoa, really? Since when??

After a lifetime of using GCC, I (like many others) moved to clang a few years ago, out of frustration with the slow development of GCC, a desire to use new C++ features, and stayed because of the superior error messages and, in my use cases anyway, superior code generation.

In addition, I gather it's a much cleaner and easier to maintain code base. As a result, we get to have cool things like emscripten, llvmpipe, all sorts of static analysis tools that would be more challenging to build in the GCC universe, and much more.

Honestly, I thought GCC was slowing down development wise.

Is GCC worth trying again? Can you name a few "cool new things" I can do with GCC that I can't with clang? There's plenty of the opposite...

LLVM always delivers the cooler stuff I'll admit but GCC is ahead as an optimizing compiler, general lang support and generating cryptic messages.

Interesting, I've generally found that clang is better at optimising, especially when it comes to auto-vectorisation.

Agreed, autovec is in my experience where clang really shines.

Gcc pretty consistently delivers slightly faster code.

Not in my experience! Though it was a few years ago, I'll have to re-evaluate. In the past, when doing numeric/scientific programming -- lots of dataflow, it was much easier to "coax" clang to generate the right (performant) assembly than GCC. I guess my use is less typical -- the internet agrees with you. :)

Hurrah for competition!

(of course, neither GCC or clang could _ever_ beat ICC at some of my tests.. grumble)

"(of course, neither GCC or clang could _ever_ beat ICC at some of my tests.. grumble)"

They never tried, honestly - ICC had plenty of defaults that were targeted at performance above correctness.

That's fine - but it wasn't what either clang or gcc was going to go for. Even when trying to compare apples to apples, folks often compared them by trying to get GCC/Clang to emulate the correctness level of ICC (IE give GCC/Clang more freedom), rather than the other way around :)

Which, again, similarly understandable, but also a thing that you'd have to spend a while on in GCC/Clang to get to a reasonable place)

Small-number-of-target compilers like ICC are also fundamentally easier. Lots of techniques (IE optimal register allocation[1], etc) that add up to performance gains are a lot more tractable to really good applied engineering when they don't have to be so general.

Similarly small-target-market compilers are also easier. Over time, high performance was literally ICC's only remaining market. So they can spend their days working on that. GCC/Clang had to care about a lot more.

[1] This happens to now be a bad example because advances finally made this particular thing tractable. But it took years more, and feel free to replace it with something like "optimal integrated register allocation and scheduling" or whatever is still intractable to generalize.

You sound like you know what you're talking about.

> They never tried, honestly - ICC had plenty of defaults that were targeted at performance above correctness.

Is it possible to get ICC level performance out of open source tools? Much of my CPU bound work relates to array signal processing, which, if you can code it right :) lends itself heavily to SIMD branchless pipelines. Plus some scatter gathers on a group of other cores to calculate a sparse crosscorrelation tensor.

I would love to be able to get same or better performing code out of clang or gcc, even it it takes 2-4x more work than with ICC...

This is often true for SPEC, but not true for real world code.

Or at least, we extensively tested this at Google, before, during, and after the move to LLVM.

On many thousands of libraries, binaries, etc, made up of hundreds of millions of lines of C++.

While there were wins and losses, on average, LLVM was a consistent net positive.

That was true despite having spent 5+ years of having a large team dedicated to doing nothing but finding places to improve performance of GCC compiled code (and contributing back patches), and doing so very successfully.

That said, as time approaches infinity, the compilers are going to generate the best code for the things that someone took the time to analyze and make the compiler better at.

There is, in the end, no magic that makes GCC better than LLVM or vice versa. The vast majority of it is tuning and improving things little by little for whatever targets someone is trying to improve.

I can only go by the results I measure. There certainly are cases where Clang does better than Gcc, but the difference is anyway rarely more than a couple of percent. Occasionally one finds a factor of two one way or the other, e.g. where one compiler has noticed it can use CMOV without penalty.

proof?

Keyword there is "slightly".

C++20 support comes to mind, the plethora of supported hardware as well.

> C++20 support?

Not that I think it matters but this is, of everything, the strongest argument to me. For shame, clang, for shame! I switched because it had better modern c++ support. Guess the winds are changing.

GCC is quite up to date. Also, the code generation used to be better. I do not know right now. But I think it still might have a slight advantage.

I've always preferred clang for its better lints, and friendlier error messages (sans some decrepit parts around templates that are equally horrendous everywhere)...

And theoretically clang has better ASM output in some cases I say theoretically, because it's been shown that GCC's "worse" ASM performs better; I'm not really an architecture aficionad, so I can't comment as to why that is.

Also, it's been a few years now since I did C/C++. So, maybe these are no longer the case.

Anyway, I've kinda pointed out what I like about clang over gcc, but I'd be curious what you prefer in gcc.

I wonder how up to date is the old belief of better error messages. The was some great redhat blogs about structured error messages in newer GCC.

GCC has gotten better indeed, but it's still in a different league than Clang. I still get into situations where I can't make heads-or-tails of what GCC is saying to me, which can usually be easily solved by switching to Clang.

One problem here is that GCC emits certain warnings as part of the optimizer, which results in many false positives that are essentially impossible for the lay programmer to understand. For example, jump threading might duplicate some code path and propagate constants in it, and then warn about an uninitialized variable / out of range access / etc in that code-path, even though it does not exist in that form in the original program.

Funny enough, this is exactly the kind of situation where other people cry "why did the compiler not warn me about basing optimizations on UB".

I don't do C++ anymore but I will forever remember the Vtable hell "messages" when doing OOP and doing a slight unintuitive mistake about destructor or constructor. Is this still a thing in clang?

Ok, that's kinda true I suppose; I remember that GCC's error messages have indeed gotten better after a major version release.

Also, when you say structured, do you mean errors over LSP, or do you mean more structure in the formatting when reporting in CLI?

GCC returns pretty nice, colored and structured error messages in CLI for quite some time.

I meant in cli a bit like rust arrows logs

clang doesn't output asm

I'm not sure what you mean? You can use `-S`

What is the status of ubsan, msan, tsan and others support for GCC though? Last time I checked they were a bit behind. I agree GCC make clang obscolete regarding C++ support and even performance. I don't know a comprehensive alternative to clang linter but I'm sure there are a few.

Given that llvm receive more human resources than gcc by far, I once expected it to outperform gcc generally (e.g support for polyhedral optimizations, BOLT, etc) Unfortunately weirdly it seems llvm performance is mostly stagnant. I personally suspect we are reaching increasingly diminishing returns with AOT and that the performance graal would be a hybrid that also does JIT at runtime (beyond PGO therefore) and more interpretable than BOLT

At work GCC is a lot slower than clang, the project uses a bit much template magic but still, clang is faster.

Where does this GCC is faster thing come from? I personally havent experienced it

I mean faster runtime performance, I have no clue about compilation time. Well I'm basing this on the countless benchmarks I've seen, e.g. on phoronix over the decade. Also you have to understand that Clang -O2 is (was) "unfair" as GCC did not enable autovectorization until -O3. This has (is being?) changed.

Old hype thing created by gcc fanboys :)

They always claims so.