we're still working on UB-related bugs we found like seven years ago because they fire ubiquitously and matter, and getting the same wins in other ways isn't so straightforward. this could be like that...
Conversation
I really liked the infinite loop / infinite recursion example that's now finally fixed. It was a pretty shocking bug in a language like Java or Rust. In C, no one cares. The code is already wrong and horribly broken anyway. Just needs to go fast and appear to still mostly work.
2
2
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
1
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
and as far as I can remember I found three major C implementations that would terminate an infinite loop, so even if you're sure about the standard then this ends up being one of those things where the standard is wrong since it disagrees with prevailing practice
1
It's not only with infinite loops but also infinite recursion and there are implementation issues with stack overflow too. I don't think the situation before -fstack-clash-protection on *nix can be considered reasonable. It also still seems wrong in terms of the standard.
1
sure, many things are a mess.
returning to noalias, either it has a semantics or not at the LLVM level. assuming that it does, there'll be some set of optimizations that disrespect the semantics, and I doubt this set will be huge.
2
1
I wasn't necessarily saying that they disrespect the semantics but rather they make mistakes and NoAlias allows them to trigger in cases they previously wouldn't have triggered, possibly because they actually use NoAlias directly themselves and then do something wrong.
1
ok, in my terminology here, "disrespect the semantics" and "make mistakes" are exactly the same thing: some element of the compiler implementation implements a transformation that isn't a refinement
1
What I mean is the mistake isn't necessarily directly related to alias analysis. Similar to how LTO, more aggressive inlining, etc. uncover many bugs in other optimizations. Gives more opportunities to screw up in other ways.
Not trying to argue about the meaning of what you said.
1