[Bug middle-end/104800] reodering of potentially trapping operations and volatile stores

[muecker at gwdg dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800

--- Comment #16 from Martin Uecker <muecker at gwdg dot de> ---
(In reply to rguenther@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))