[PATCH] Fix PR middle-end/26306

[Richard Kenner]

> 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 agree.

> 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.  

I haven't looked at the usage in Ada yet, actually.

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

I'm not sure what this means and my concern is that it burdens a front
end with looking into trees for lower-level volatile operands.

Consider global definitions:

	volatile int vi;
	int i;
	volatile struct vs {int f,g, h; } vs[10];
	struct s {int f, g, h; } s[10];

Now consider
	vs[i]
	s[vi]

both are TREE_SIDE_EFFECTS.  In the former case, it's because we're generating
the BLKmode reference to a part of VS, which we're to ignore, but in the
latter, it's the inner reference to the volatile VI that's what must not
be ignored, though the access to the memory into S need not be generated.

I don't think a front end should be trying to distinguish between these cases:
we already have a lot of almost-working code in the middle-end (specifically
the gimplifier) to do this.