[Ada] Fix bugs with volatile and components of aggregate types

Michael Matz matz@suse.de
Mon Jun 20 14:20:00 GMT 2011


On Sun, 19 Jun 2011, Mike Stump wrote:

> >> if T is a non-volatile composite type with volatile components, and O 
> >> is an object of type T, are the optimizers allowed to remove the 
> >> assignment "O := O"?
> > 
> > Good question, that I'm not really qualified to answer.  Any language 
> > lawyer?
> I'd like to think that the optimizers are not allowed to remove the 
> assignment (unless they synthesize of up the assignment of all volatile 
> fields).  For unions, head explodes.  I think for unions, it can.  I 
> could check the standard to ensure I have it right, but, well, that's 
> annoying.  :-)  This answer is for the answer for C and C++, but, the 
> middle end, _could_ decide to differ, if it had a compelling reason to.  
> I don't know of any reason.  Now, before someone tries to optimize 
> structures, please be very careful.  Unions, transparent unions, 
> frontend synthed structures with multiple offsets at the same location 
> and the like come to mind.

The middle end really can't decide.  See also PR45472, from comment #7:

This all points to a deeper problem IMO, one we need to decide how to 
solve before tackling the details of this bug, namely: how are 
non-volatile objects containing volatile subobjects handled?  I don't know 
if the language standard says anything about this.

We have several possibilities:
1) make all objects containing volatile subobjects volatile itself
2) make instructions touching such objects volatile
3) make instructions touching the volatile components volatile

The first has the problem that volatile objects with aggregate type
implicitely contain only volatile subobjects, that is for such object:
  struct {int a; volatile int b;} half_volatile;
with solution (1) this would be equivalent to
  volatile struct {int a; volatile int b;} half_volatile;
and hence halt_volatile.a would be volatile too, probably unlike the
author intended.

The other two solutions are more work, especially because the
half-volatility wouldn't be reflected in the objects type.

Downwards we decided that it's really the languages business to define
half-volatility, so it either needs to or doesn't need to emit volatile
mem_refs according to its standard.


More information about the Gcc-patches mailing list