[PATCH] Fix PR middle-end/26306

[Mark Mitchell]

Eric Botcazou wrote:
>> However, if we do want to do this in the middle end, then checking
>> TREE_ADDRESSABLE (rather than AGGREGATE_TYPE_P) might be better?  Not
>> all aggregates have BLK_MODE, so the analogy with 3.4 isn't completely
>> accurate.
> 
> Hum... what's the relationship between TREE_ADDRESSABLE and BLKmode?

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. 
For a non-TREE_ADDRESSABLE type, you can just create a temporary, copy 
the value into the temporary; that creates the memory access.

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

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.

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.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713