https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #16 from Martin Uecker <muecker at gwdg dot de> --- (In reply to rguent...@suse.de from comment #14) > On Wed, 9 Mar 2022, muecker at gwdg dot de wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800 > > > > --- Comment #12 from Martin Uecker <muecker at gwdg dot de> --- > > (In reply to Richard Biener from comment #10) > > > Btw, with -ftrapv it would mean we cannot re-order any signed arithmetic > > > with respect to volatile accesses unless we can prove it does not invoke > > > (undefined, > > > but -ftrapv makes it implementation defined) signed overflow. > > > > > > Yes, and I think this would be desirable too. For example, if you safetly > > turn > > off a machine with a volatile store, you want a later logic error in > > unrelated > > code not to be able to prevent this. > > As said, volatile accesses are not considered to alter control flow and > thus "turning off the machine" is not something GCC "allows", the > program has to resume after the volatile store. Sorry, I was not clear. I agree that volatile accesses are not meant to alter control flow according to the C standard (although the assumption that they may terminate the program may be one possible way to express their semantics for optimization). With "turning off a machine" I meant an external device controlled by a C program. For sake of argument: moving the control rods into a nuclear reactor. > For example volatile accesses are also not considered to abnormally > return. Consider them raising an interrupt, that triggering a signal > and using siglongjmp - GCC is not prepared for that to happen > (so it's not "allowed"). > > The following might be eventually a catch-all fix (but too aggressive > as noted in the comment). With it GCC should consider (on the > GIMPLE / GENERIC level ...) all volatile accesses possibly trapping > and thus altering control flow. > > diff --git a/gcc/tree-eh.cc b/gcc/tree-eh.cc > index c37a5845343..21179081be9 100644 > --- a/gcc/tree-eh.cc > +++ b/gcc/tree-eh.cc > @@ -2662,8 +2662,15 @@ tree_could_trap_p (tree expr) > return false; > > code = TREE_CODE (expr); > - t = TREE_TYPE (expr); > + /* Volatile accesses need to be considered as altering control flow > + if they are for example device I/O. > + ??? We can probably exclude automatic variables and accesses that > + are known to not map to device memory here. */ > + if (TREE_CODE_CLASS (code) == tcc_reference > + && TREE_THIS_VOLATILE (expr)) > + return true; > > + t = TREE_TYPE (expr); > if (t) > { > if (COMPARISON_CLASS_P (expr))
