Re: Volatile qualification on pointer and data

[David Brown <david at westcontrol dot com>]

On 20/09/2011 18:35, Ian Lance Taylor wrote:
> "Paulo J. Matos"<paulo@matos-sorge.com>  writes:
>
> > The following code:
> > static const unsigned int foo = 1;
> > unsigned int test( void )
> > {
> >    const volatile unsigned int *bar =&foo;
> >    return ( *bar );
> > }
> >
> > in GCC45 works as expected:
> > $test:
> >    ld AL,#foo  ;; AL is return register
> >    bra 0,X     ;; end function
> >
> > in GCC46:
> > $test:
> >    ld AL,0
> >    bra 0,X
> >
> > This is worrying because qualifying the data as volatile should be
> > enough to prevent these sort of optimizations. It did until GCC46.
>
> I agree that this looks like a bug.  Please file a bug report marked as
> a regression.
>
> Ian

Are you sure about that?  In the declaration of "bar", the "const" part 
is just a promise to the compiler that the code won't try to change the 
data pointed to by bar.  But when "foo" is defined as "const", that 
tells the compiler that foo cannot change, and being "static" and 
non-volatile, the compiler then knows everything about foo and can 
eliminate it in the code.  Asking to read it by a volatile read does not 
change the nature of "foo" - the compiler can still implement it as a 
compile-time constant.  So the compiler does it's best to generate code 
for a volatile read of an immediate constant.

David