That's just broken, but not too surprising, since it's not uncommon for compilers to have miscompile bugs in tough and unusual corner cases. But the context of this conversation is: do you need a new compiler to fix UB?
Conversation
The fact that llvm has bugs doesn't really change the answer. Even a compiler that was designed to avoid UB could have miscompile bugs. Also, the context of the conversation allows for making changes to llvm - so this seems like the kind of thing that could be fixed.
1
1
I guess I don't understand the context. It seems to be about C, and I don't see how you can resolve that problem for C without coming up with a model to enforce a form of memory safety. What is the scope of UB that should be avoided? You mean, for a language like Rust or Swift?
2
I was just responding about the infinite recursion thing, particularly because I don't believe that's actually undefined in C. It doesn't talk about a stack, let alone saying that overflowing it in undefined or that infinite recursion can just be removed. I think that's wrong.
1
I don't think features like opt-in to undefined behavior on signed or unsigned overflow (nsw, nuw) are an issue in LLVM since frontends can avoid emitting it (like Rust and Swift). It's only a major issue when there isn't a decent alternative or when UB is poorly defined/unclear.
1
For example, various shifts, casts and floating point operations are undefined, so if you want to use them safely you need to wrap everything in branches which the compiler is unlikely to optimize out. I think the solution to that is just providing more specific variants of them.
2
If you want overflow to be handled a certain way, you would use the instruction for those semantics and it would just be lowered inefficiently on architectures without native support. If you want efficiency you could have the frontend switch it based on the architecture targeted.
1
LLVM is overly focused on C and takes too many shortcuts that are allowed for C but don't work for other languages. When someone talks about these issues for C, I don't really get the point. These issues are what goes horribly wrong for C in the real world even in 1% of cases.
1
But you can make C not have the UB issues while retaining the ability to fuck with memory directly. Such a thing can be defined and it’s what lots of systems code expects.
1
No, memory unsafety is by far the biggest issue. The compiler certainly heavily optimizes with the assumption that memory safety is not violated. It's a far more extreme situation than optimizations based on the assumption that signed int overflow doesn't happen, etc.
2
If you have a struct foo { int a[4]; int b[4]; } and you write 1 past the end of the field a, you're absolutely not guaranteed to have it land inside b and you cannot even have a reasonable expectation of that. The compiler will often be splitting this apart with SROA and so on.
SROA could trivially treat oob gep as escape and wouldn’t do anything if the index is variable and of unknown bound. Even if this is an issue in llvm, it’s far from a fundamental issue.