Re: volatile qualifier hurts single-threaded optimized case

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 8/30/06, Paolo Carlini <pcarlini@suse.de> wrote:
> Richard Guenther wrote:
>
> > They can be still used by putting appropriate const_cast<> on the rope
> > side.  If
> > in the threaded case we dispatch to the threaded variants, volatile
> > will be in effect again.
>
> This is becoming slightly off-topic, but I'm interested to understand
> this detail better, I think there is also something about it in that
> long thread but there were different opinions. Therefore, you are saying
> that, in gcc at least, using plain pointers together with volatile
> memory is ok? I seemed to remember that, in some cases, in gcc, the type
> of the pointer counts "more" than the type of the memory, so to speak.

Well, there is 6.7.3/5 which not exactly applies to this case:

"If an attempt is made to modify an object defined with a
const-qualified type through use
of an lvalue with non-const-qualified type, the behavior is undefined.
If an attempt is
made to refer to an object defined with a volatile-qualified type
through use of an lvalue
with non-volatile-qualified type, the behavior is undefined."

whether this allows

int i;
volatile int *p = &i;
*p;

*p to be accessed as it's effective type (unqualified int) I cannot
answer from the
standard (though this rule applies for const qualification).  I think
this question
came up before and we concluded to not wanting to break code that does

int *p;
while (*(volatile int *)p)
  ;

Richard.