So, even though it's known that this is broken for many years, they have kept the optimization enabled. No one has been motivated to deal with implementing a 'halts' attribute and adding support for detecting / propagating it in the function attribute pass and making it required.
Conversation
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?
1
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.
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.
1
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.
Biggest issue for what? Crashes? Security? Or this conversation? Because this conversation isn’t about fixing the fact that C programs may crash or have other bugs. It’s about the compiler and spec exacerbating the problem with bugs that arise from an overly symbolic spec.
1
The compiler and specification certainly exacerbate the problem of spatial and temporal memory safety issues by not guaranteeing that they trap, which they could do and it could be quite realistically implemented. What makes that outside the scope of a compiler issue? It is one.
1
Show replies