Re: [PATCH] Fix PR middle-end/26306

[Mark Mitchell <mark at codesourcery dot com>]

Richard Kenner wrote:
>> I don't particularly relish documenting the BLKmode-ness check,
>> since I don't know how users will be able to work out when an object
>> has BLKmode
> 
> That, of course, is the argument in favor of using AGGEGATE_TYPE_P despite
> the potential incompatibility.

Yes, AGGREGATE_TYPE_P has more easily documented semantics, if we are
determined to do this in the middle end.  I don't think they're the best
semantics, but they are well-defined.

I still don't understand why fixing this in the Ada front-end, or in
the conversion from Ada to TREE/GIMPLE, is off the table.  Right now, it
sounds like we have three alternatives.  (See below.)  None is perfect.

1. Middle-end treats BLKmode as a no-op.

Advantages:

* Backwards compatibility.

Disadvantages:

* Semantics are hard to define for users, as it relies inherently on an
implementation detail.  (What if we sometime decide to treat "struct S {
char a; char b; };" as HImode?  What if that happens on some platforms,
but not others?)

* May not be the best choice for C/C++, where it seems reasonable to
treat such volatile accesses as reads, despite the fact that the exact
ordering of byte/short reads, etc., is unspecified.

2. Middle-end treats AGGREGATE_TYPE_P as a no-op:

Advantages:

* Well-defined semantics.

Disadvantages:

* May not be the best choice for C/C++, where it seems reasonable to
treat such volatile accesses as reads, despite the fact that the exact
ordering of byte/short reads, etc., is unspecified.

3. Front-ends must ensure volatile lvalues can be read/copied.
Middle-end generates code for all volatile lvalues.

Advantages:

* Well-defined middle-end semantics.

Disadvantages:

* Front ends have to check for things they cannot copy.

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