https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- Generally GCCs middle-end considers volatile stores (or loads) to not have any side-effects that are not visible in the IL. That includes (synchronous) raise of signals (and thus effects on control flow), effects on other (non-volatile) memory, etc. If a volatile access has to be considered having an effect on control flow then the standard should explicitely mention that, I don't think it does that at the moment, it merely says those statements invoke "changes in the state of the execution environment" So volatile "issues" like this are no different from issues that arise with respect to observability when you consider asynchronous events and the effect of re-ordering of statements. In fact C17 especially notes that objects that are not volatile sig_atomic_t have unspecified value on such events, so that IMHO also covers generating a trap from a volatile access. Volatile accesses are deemed observable but we do not re-order those, this bug is about re-ordering unrelated stmts with respect to such accesses. I don't think the standard requires us to fix this reported behavior. A mitigation in the middle-end requires volatile accesses to behave as possibly altering control flow. That's iffy if they continue to be represented as simple assign statements, the closest would be to always mark them as possibly trapping (something we cannot do right now). The PRE "fix" is just covering up a single place in the compiler that fails to consider volatile accesses as altering control flow.
