Re: volatile semantics

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:

 Nathan> Dale Johannesen wrote:
 >> However, as a QOI issue, I believe the compiler should treat the
 >> reference as volatile if either the object or the lvalue is
 >> volatile.  That is obviously the user's intent.

 Nathan> I'm not disagreeing with you, but I wonder at gcc's ability
 Nathan> to make good on such a promise.  A cast introducing a
 Nathan> volatile qualifier will be a NOP_EXPR, and gcc tends to strip
 Nathan> those at every opportunity.

Is that true only for casts that add the volatile qualifier but
otherwise do nothing?  A quick tests suggests yes.

This change bothers me a lot.  It seems likely that this will break
existing code possibly in subtle ways.  At least it doesn't do this
when the cast is from a constant integer into a volatile int * --
which is common syntax for CSR references.

Still, never mind what the C spec appears to say, optimizing away the
cast cannot possibly what the user intended.  If the standard implies
that this is right, I'd argue that's a standards bug.  In any case,
such a transformation should at least generate a warning.  Preferably
it should revert to the old semantics.

     paul