Thread: I encourage everyone to have a glance over the Quake II source code

Epy: does it generate UD2 instructions when doing an AOT build, or only in JIT mode?

Originally Posted by Epy

Re-read everything I wrote and tell me what is more likely:

As you know, what is more likely or not is of no significance. What matters is who is correct, and you can only figure that out by testing it properly. If it's the code that's wrong (more likely), then it should be fixed. If it's clang that's wrong, a bug report should be filed. Otherwise it's not going to be fixed.

a) Clang is the only compiler on the planet that can supposedly catch this mysterious undefined behavior, uncatchable by its own sanitizers and -Weverything, which apparently has been ignored/uncaught by numerous other compilers, static analyzers, and professional/open-source software developers since the early 1990s.

I know of no other compiler that inserts traps that check for undefined behaviour. And again, static analysers can only find so much. Some errors will only be found at runtime. So why is this so surprising to you?

b) These other compilers, GCC, MSVC, Intel C++, etc., all serious, production-level compilers, process this code without major warnings/errors and produce binaries that work as intended/expected, and have for years because the code is "correct" (enough). OCE is definitely not perfect, but at most is guilty of type punning in terms of undefined behavior. Thing is, what crashes does not correlate with where the type punning takes place in the code.

Perhaps because you're relying on undefined behaviour and it just "happens" to work, but it's a ticking time bomb. Clang catch it because it actively searches for UB.

Also, whats with the "your"? Again, this is code developed by professionals, professionals with graduate degrees in CS, not just anyone can program a CAD kernel.

"You" can mean you specifically or you and your team because there's so differentiation between singular you and plural you in english that I know of.
And you know, even if it's developed by people with graduate degrees in CS or so-called "professionals", I'm not convinced AT ALL that they're writing good code. There's so much garbage out there it takes one to see it to believe it.

Originally Posted by Epy

From what you wrote, it sounds like Clang's stance is "I don't know if this *could* be undefined behavior, so I'm going to take a massive dump on your executable, even though I'm not sure."

My question is then why don't other compilers do this? The answer is, because other compilers are sane. The sane thing to do is produce a warning saying "this line could be undefined behavior" and then try anyway, because it doesn't know if it's undefined behavior or not.

The answer is that the other compilers are insane and clang is doing you a favour. UB should not be there. Period.
Thing is, potentially ANY line could be UB. Your loops could be UB. Your null checks could be UB. Your bit shifting could be UB. Your array indexing could be UB. You want the compiler to dump a warning for every one of these lines? That's going to be a LOT of warnings of which you can probably never really "fix".

Let's get this part correct. Your code with undefined behavior doesn't work.

O_o

Indeed. We need to get this part correct.

I know that "Clang++" had a bug during the early "3.$" days which resulted in spurious traps showing up in compiled binaries in certain situations.

You may verify the fact that "Clang++ 3.$" had such a bug at your leisure.

We agree that the code may simply exhibit undefined behavior.

You are ignoring at least three other possibilities: the "Clang" layer is recognizing code as exhibiting undefined behavior while not reporting such important information; the "Clang" layer is emitting the undefined behavior trap because the behavior of the relevant code can't positively be recognized as exhibiting only defined behaviors; the "Clang" layer is optimizing the produced intermediate in such a way that "LLVM" is forced to emit the undefined behavior trap.

If "Clang" is recognizing undefined behavior without reporting such valuable information even when exactly such information is requested, "Clang" has a bug which needs to be fixed.

If "Clang" is emitting the undefined behavior trap because the relevant code can't be recognized as having only defined behaviors, "Clang" has a bug which needs to be fixed.

If "Clang" is producing an intermediate which must exhibit undefined behavior, "Clang" has a bug which needs to be fixed.

The answer is that the other compilers are insane and clang is doing you a favour. UB should not be there. Period.
Thing is, potentially ANY line could be UB. Your loops could be UB. Your null checks could be UB. Your bit shifting could be UB. Your array indexing could be UB. You want the compiler to dump a warning for every one of these lines? That's going to be a LOT of warnings of which you can probably never really "fix".

o_O

"Clang" would be doing developers a favor emitting undefined behavior traps for code which isn't known to exhibit undefined behavior?

The compiler issuing numerous warnings "you can probably never really fix" is a problem, but the compiler emitting undefined behavior traps for code not recognized as exhibiting only defined behaviors is a favor? Really? You wouldn't think the false negatives would also be difficult to fix?

Soma

I don't know where they emit traps. I'm fine with them emitting traps for things such as dereferencing null pointers or other things that will invoke UB. Hey, compilers have bugs. It's something we just have to live with. Optimization and code emissions have bugs. When we encounter these bugs, we just have to try to work around them. I don't see how it's any different with these traps. All these types of bugs can result in incorrect code generation, and the former two exist today already.

Hey, compilers have bugs.

O_o

Indeed.

I don't see compiler bugs getting fixed with the "The behavior you are complaining about doesn't affect me so must not be a real issue." on display from some of the people in this thread.

For all I know, the code Epy is referencing might be garbage. Fine. I'm with you.

I also know "Clang" has bugs so see no reason to give the "Clang" developers a pass on the lack of optional reporting.

Wouldn't it be interesting if we could say to Epy "Oh, you should compile with the `-Weverythingnoreallyimeaneverything` flag to get more information about which code is generating a trap with and without optimizations."? The spurious warnings and errors aren't as significant as you might think when one can compare the messages generated with different options.

I don't see how it's any different with these traps.

I also don't see how it's any different.

You expect the developers to work at fixing and hopefully fix the other bugs, and you've certainly ranted about the bugs that have affected you.

All these types of bugs can result in incorrect code generation, and the former two exist today already.

o_O

We aren't talking about some new or unrelated class of bug.

The occurrences of earlier bugs related to undefined behavior traps are the result of optimizations and code emission bugs.

The issue Epy is seeing could literally be a developer restoring an old bug in effort to fix some other problem.

Soma