it's not that nobody cares, it's that the standards committees explicitly decided to make compiler writers' jobs easier by making certain loops UB, and the LLVM compiler writers took advantage of the allowed leeway
Conversation
That's true for C++ but it was definitely a correctness bug in Clang for C.
1
1
well, I explored that somewhat here and it's not necessarily as clear-cut as you suggest blog.regehr.org/archives/161
2
1
We discussed this before. Loops with constant controlling expressions are explicitly not UB in C. Clang's optimization was (is?) structured in such a way that this got forgotten on some examples. An optimization that mistranslates one defined program is an incorrect optimization.
2
1
I believe the history we're discussing significantly predates any language in the standard about a constant controlling expression, right?
1
Your blog posts are from mid-2010 and the wording was added to C11 (port70.net/~nsz/c/c11/n15 port70.net/~nsz/c/c99/n12 ). It may already have been in the draft.
1
In fact, didn't the C11 standard have the rule that any change must already be implemented in a compiler? In this case it couldn't be standardized much earlier.
remains right that Clang was miscompiling some infinite loops in C11 programs in 2020.
1
(If it already had the same optimization, Clang was also miscompiling both C99 and C11 programs in 2010, so again I don't see how it would be wrong to call this a clear-cut compiler bug throughout.)
1
I talked to people before writing that blog post and, I believe, did a reasonably good job summarizing the differences in views on this topic in it
1
Here's an example:
gist.github.com/thestinger/2a1
This program definitely shouldn't be printing "launch nukes".
Beyond that, I think the libc implementation should be catching the stack overflow and stalling the thread.
At least in my opinion, it's well defined as yelling forever.
