[PATCH] Fix PR middle-end/26306

[Eric Botcazou]

> None, but TREE_ADDRESSABLE is what says that you can't copy type by just
> copying bits about, and that's the situation that's problematic here.

OK, sorry for being terse in my initial message, TREE_ADDRESSABLE is 
orthogonal to the Ada problem.

> For a non-TREE_ADDRESSABLE type, you can just create a temporary, copy
> the value into the temporary; that creates the memory access.

No, we can't always do that for variable-sized types, that's the ICE.

> Of course, AGGREGATE_TYPE_P is not the same as BLKmode either.

It's the best approximation without getting dirty.  Of course we can check 
TYPE_MODE if you prefer.

> I don't think consistency with 3.4 should be the paramount goal here.
> The goal should be to avoid ICEing, and, hopefully, do something with
> semantics that are readily explained.  At least for C++, we could have
> avoid ICEing by checking TREE_ADDRESSABLE -- but instead, Jason chose to
> handle this in the front end.

Well, something is (partially) wrong in the middle-end, namely

else if (COMPLETE_TYPE_P (TREE_TYPE (*expr_p)))
        {
          /* Historically, the compiler has treated a bare
             reference to a volatile lvalue as forcing a load.  */

and these wrong bits break the Ada compiler.  Since the only justification 
appears to be the historical one, I think history should not be rewritten.

That Jason fixed the C++ problem in a different manner should not preclude us 
from recognizing that the semantics has changed from 3.x to 4.x and, I would 
suspect, by accident.

> That seems best in that it avoids having to define the middle-end
> semantics conditionally.  Instead, we simply say that a volatile read,
> to the middle end, means the semantics I gave above in terms of copying
> to temporaries.  It's the front-end's responsibility to make sure that
> the middle-end never sees a volatile read where copying to a temporary
> is not an option.

Why fixing the problem multiple times in different front-ends while simply 
reverting to the 3.x semantics of the middle-end would do it?  Moreover, you 
said in a previous message that 'volatile' doesn't really apply to aggregates 
in C/C++, so why invoking the C++ front-end here?  I'd think that if these 
middle-end bits are only really meaningful for the Ada compiler, let's change 
them back in accordance with what the Ada front-end has been generating from 
the very beginning.

-- 
Eric Botcazou