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

[Mark Mitchell <mark at codesourcery dot com>]

Richard Kenner wrote:

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

Yes, that's true; the front end would have to distinguish between values
that are used and values that are not, in that the front end must never
generate an unused volatile value for an aggregate that cannot be
copied.  In C++, we already distinguished between used and unused
values, so this was not a big deal.

> 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 we should ignore vs[i]; that's an expression of type
"volatile int", and should trigger a read from the appropriate location.
 I thought the case in questions was just plan "vs;".

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

I think we're stuck.  Fundamentally, I think references to volatile
structures (e.g., "vs;" in your example) should generate reads.  You
apparently think they shouldn't.  GCC historically thought they should
only if "vs" did not have BLKmode type.  It seems to me that only the
first of these three choices (read from the structure) has logical
semantics.  The second makes volatile meaningless on aggregates, which
seems under-expressive; users can already get those semantics by not
saying "volatile".  The third depends on GCC's internals, which seems
bad from the perspectives of documentation, maintenance,
consistency-over-time, and consistency-across-platforms perspective.

But, I am burned out on arguing about it.  Realistically, there aren't
many C/C++ programs that use volatile structures types in this way, so
the number of real-world programs that could benefit from the automatic
read is probably very small.  I promise not to comment further and I
apologize for picking nits about a minor issue.

Thanks,

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