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
The question of whether memory unsafety implies UB is sort of at the heart of the disconnect between the C spec and C practitioners. As a practitioner (and compiler guy) I view memory unsafety as a separate thing - after all a “bad” store still stores to a well defined place.
2
1
2
There is nothing well defined about what an out-of-bounds access or use-after-free will access. The compiler, linker and even runtime environment are assuming that is never going to happen and there's nothing defined about what the consequences are going to be from the C code.
3
1
In the machine code output by the compiler, it's perfectly well defined what an out-of-bounds access or use-after-free will do, and to what, although of course it depends on runtime state. It's just undefined in the input C code.
1
2
That's not a relevant response related to the thread. He states that he wants an optimizing compiler with a comparable amount of optimization, where the programmer is writing code for an abstract machine and the compiler is making transforms that preserve abstract semantics.
1
That wasn't my interpretation of his Tweet at the time, but on looking at further context, I think you are correct
1
I would definitely say that the standard should not say things are 'undefined' but rather come up with sensible constraints on how it should be implemented. Guaranteeing that signed overflow wraps would be a regression for safe implementations by forbidding them from trapping.
2
1
Guaranteeing it either wraps or immediately traps would also be a regression, by forbidding more efficient implementations that trap as late as possible by propagating overflow errors via poison bits or poison values. UBSan is explicitly not designed as efficient. It's difficult.
I do think the standard should forbid treating signed overflow as something that is guaranteed to never happen in order to optimize further, and the same goes for other cases like this. It's near impossible to do that for memory safety issues without requiring safety though.
1
1
I think that's going to be a hard sell to compiler vendors — doesn't it mean people will have to rewrite their inner loops with size_t loop counters to get reasonable efficiency?
1
Show replies