7 ms·
It follows from the definition of UB: undefined behavior: "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which t
by uecker 4d ago
It follows from the definition of UB:
undefined behavior: "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements"
The C++ spec at some point changed this to explicitly allow changing anything in the program not just the specific behavior implied by the "for which". The C spec never did this.
Because people were confused about this, in C23 we added the following note. "Note 3 to entry: Any other behavior during execution of a program is only affected as a direct consequence of the concrete behavior that occurs when encountering the erroneous or non-portable program construct or data. In particular, all observable behavior (5.1.2.4) appears as specified in this document when it happens before an operation with undefined behavior in the execution of the program."
Compilers mostly follow this. GCC has bugs related to volatile. Clang often follows the C++ standard, where it is different from C, so probably does not conform to the standard here (as for some other things).
The new C++ standard will have UB "barrier", i.e. std::observable that will limit the effect of UB to things before this barrier.
- titzer 4d agoThanks for pointing to this. I'm surprised the specification verbiage differs so much between the two standards. However I think the language for C is aspirational and there are cases where compiler optimizations will fail this.
- uecker 4d agoThere are a few rare cases where compiler optimization will fail this in GCC. There are also cases where the C spec has defined behavior that optimizers break. Where I know about them, I file bugs. It would be up for users to insist that those get fixed. This includes optimization issues that affect Rust as well.
- Georgelemental 4d agoSome of those cases have been fixed. For example, Clang used to reorder UB around volatile loads, but the latest version no longer does so.
- uecker 4d agoThis is good news! Clang representatives were very basically the only ones against this clarification. Do you have a pointer?
- Georgelemental 4d agohttps://llvm.org/docs/LangRef.html#volatile-memory-accesses https://llvm.org/docs/LangRef.html#volatile-memory-accesses: > Volatile operations are permitted to trap. The compiler may not assume that execution will continue after a volatile operation.