That argument would make more sense if they actually were faster, which they often aren't. Last I checked (and I don't keep up with this, to be fair) they still lagged gcc on most macrobenchmarks on x86.

> they still lagged gcc

Isn't the "they" in this thread gcc, or did I misread something?

I took "clang/llvm may be reckless, but they're fast and have UBsan", to which I replied "gcc is still faster".

Oh, I thought the GP was accusing GCC devs of reckless optimizations. But UBSan is a clang project, so maybe you're interpretation makes more sense. Very confusing thread. :)

Sorry, I should've been more explicit when I responded to the original clang vs gcc comment.

Note that UBSan is (mostly? totally? originally?) a Google project and it's been ported to both clang and gcc.

I mean, if you use GCC does recklessly optimize away (some) security/safety code. This is one of the reasons why we don't use it for code we ship. I work in a safety-conscious industry, where an overeager compiler can literally kill people.

Umh.. the compiler writers don't "exploit undefined behaviour".

The compiler writers write the compiler with the expectation that the program being compiled is correct i.e. to the specification.

Now when the program fails to be correct, optimizations can result in "weird" results, which is not really incorrect since the input was incorrect.

UBSan catches undefined behavior at runtime - so by definition everything it reports was not used by Clang to fold your program to a constant.

When the sanitizer is on, the optimizer (modulo bugs of course) does not remove the checks.