Volatile qualification on pointer and data

Volatile qualification on pointer and data

[Paulo J. Matos]

Hi,

I am noticing a very concerning change of behaviour from GCC45 to GCC46 
on our applications.

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 noticed that this seems to be implementation dependent according to 
C99 6.7.3.6, however, this change of implementation is unexpected and I 
don't see a reason for it. Is there any reason for this change?

The correct code is generated is both the pointer and data are qualified 
as volatile even it is not straightforward code since it has some moves 
to and from the stack pointer.

This is easily reproducible in i386 so, it's definitely not backend 
specific.

Cheers,
-- 
PMatos

Re: Volatile qualification on pointer and data

[Ian Lance Taylor]

"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

Re: Volatile qualification on pointer and data

[David Brown]

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

Re: Volatile qualification on pointer and data

[Paulo J. Matos]

On 21/09/11 08:03, David Brown wrote:
> 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.

But since I am accessing the data through the pointer and the pointer 
qualifies the data as volatile, shouldn't the compiler avoid this kind 
of optimization for reads through the pointer?

It still is a regression from GCC45, however it might be considered a 
feature instead of a bug as I already mentioned to Ian.

-- 
PMatos

Re: Volatile qualification on pointer and data

[David Brown]

On 21/09/2011 10:21, Paulo J. Matos wrote:
> On 21/09/11 08:03, David Brown wrote:
>> 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.
>
> But since I am accessing the data through the pointer and the pointer
> qualifies the data as volatile, shouldn't the compiler avoid this kind
> of optimization for reads through the pointer?
>

My thought is that the nature of "foo" is independent of how it is 
accessed.  On the other hand, some uses of a variable will affect its 
implementation - if you take the address of "foo" and pass that on to an 
external function or data, then the compiler would have to generate 
"foo" in memory (but in read-only memory, and it can still assume its 
value does not change).  So I am not sure what the "correct" behaviour 
is here - I merely ask the question.

Fortunately, this situation is not going to occur in real code.

> It still is a regression from GCC45, however it might be considered a
> feature instead of a bug as I already mentioned to Ian.
>

Re: Volatile qualification on pointer and data

[Ian Lance Taylor]

David Brown <david@westcontrol.com> writes:

> On 21/09/2011 10:21, Paulo J. Matos wrote:
>> On 21/09/11 08:03, David Brown wrote:
>>> 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.
>>
>> But since I am accessing the data through the pointer and the pointer
>> qualifies the data as volatile, shouldn't the compiler avoid this kind
>> of optimization for reads through the pointer?
>>
>
> My thought is that the nature of "foo" is independent of how it is
> accessed.  On the other hand, some uses of a variable will affect its
> implementation - if you take the address of "foo" and pass that on to
> an external function or data, then the compiler would have to generate
> "foo" in memory (but in read-only memory, and it can still assume its
> value does not change).  So I am not sure what the "correct" behaviour
> is here - I merely ask the question.
>
> Fortunately, this situation is not going to occur in real code.

I think your description is supported by the standard.  However, I also
think that gcc should endeavor to fully honor the volatile qualifier in
all cases, because that is least surprising to the programmer.  This is
not a case where we should let optimization override the programmer's
desire; by using volatile, the programmer has explicitly told us that
they do not want any optimization to occur.

Ian

Re: Volatile qualification on pointer and data

[David Brown]

On 21/09/2011 15:57, Ian Lance Taylor wrote:
> David Brown<david@westcontrol.com>  writes:
>
>> On 21/09/2011 10:21, Paulo J. Matos wrote:
>>> On 21/09/11 08:03, David Brown wrote:
>>>> 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.
>>>
>>> But since I am accessing the data through the pointer and the pointer
>>> qualifies the data as volatile, shouldn't the compiler avoid this kind
>>> of optimization for reads through the pointer?
>>>
>>
>> My thought is that the nature of "foo" is independent of how it is
>> accessed.  On the other hand, some uses of a variable will affect its
>> implementation - if you take the address of "foo" and pass that on to
>> an external function or data, then the compiler would have to generate
>> "foo" in memory (but in read-only memory, and it can still assume its
>> value does not change).  So I am not sure what the "correct" behaviour
>> is here - I merely ask the question.
>>
>> Fortunately, this situation is not going to occur in real code.
>
> I think your description is supported by the standard.  However, I also
> think that gcc should endeavor to fully honor the volatile qualifier in
> all cases, because that is least surprising to the programmer.  This is
> not a case where we should let optimization override the programmer's
> desire; by using volatile, the programmer has explicitly told us that
> they do not want any optimization to occur.
>

That makes sense - the principle of least surprise.  And since this 
situation would not occur in real code (at least, not code that is 
expected to do something useful other than test the compiler's code 
generation), there is no harm in making sub-optimal object code.

Are there any warning flags for "programmer doing something technically 
legal but logically daft", that could be triggered by such cases? :-)

Re: Volatile qualification on pointer and data

[Paulo J. Matos]

On 21/09/11 15:21, David Brown wrote:
> And since this
> situation would not occur in real code (at least, not code that is
> expected to do something useful other than test the compiler's code
> generation), there is no harm in making sub-optimal object code.
>

Actually the reason why I noticed this is because one of our engineers 
told that GCC stopped generating instructions for certain operations 
when he moved from GCC45 to GCC46. This code is real code.

Cheers,
-- 
PMatos

Re: Volatile qualification on pointer and data

[David Brown]

On 21/09/2011 16:57, Paulo J. Matos wrote:
> On 21/09/11 15:21, David Brown wrote:
>> And since this
>> situation would not occur in real code (at least, not code that is
>> expected to do something useful other than test the compiler's code
>> generation), there is no harm in making sub-optimal object code.
>>
>
> Actually the reason why I noticed this is because one of our engineers
> told that GCC stopped generating instructions for certain operations
> when he moved from GCC45 to GCC46. This code is real code.
>
> Cheers,

If you really have a "static const" object which you need to read as 
"volatile" for some reason, then I would seriously consider changing the 
code.  With "static const" you are telling the compiler it knows 
everything about the use of that object, and its value will never change 
- with "volatile" you are telling it that it's value might change behind 
the scenes.  Obviously you've only posted a code snippet and not your 
full code, but that sounds self-contradictory to me.  Somewhere along 
the line you are lying to the compiler - that's never a good idea when 
you want correct and optimal code.

David

Re: Volatile qualification on pointer and data

[Richard Guenther]

On Wed, Sep 21, 2011 at 4:57 PM, Paulo J. Matos <paulo@matos-sorge.com> wrote:
> On 21/09/11 15:21, David Brown wrote:
>>
>> And since this
>> situation would not occur in real code (at least, not code that is
>> expected to do something useful other than test the compiler's code
>> generation), there is no harm in making sub-optimal object code.
>>
>
> Actually the reason why I noticed this is because one of our engineers told
> that GCC stopped generating instructions for certain operations when he
> moved from GCC45 to GCC46. This code is real code.

Btw, I think this is an old bug that has been resolved.  Did you make sure to
test a recent 4.6 branch snapshot or svn head?

> Cheers,
> --
> PMatos
>
>

Re: Volatile qualification on pointer and data

[Paulo J. Matos]

On 22/09/11 22:15, Richard Guenther wrote:
>
> Btw, I think this is an old bug that has been resolved.  Did you make sure to
> test a recent 4.6 branch snapshot or svn head?
>

Should have tested git head. Compiling git head now to check the current 
status of this issue.


-- 
PMatos

Re: Volatile qualification on pointer and data

[Paulo J. Matos]

On 23/09/11 12:33, Paulo J. Matos wrote:
> On 22/09/11 22:15, Richard Guenther wrote:
>>
>> Btw, I think this is an old bug that has been resolved. Did you make
>> sure to
>> test a recent 4.6 branch snapshot or svn head?
>>
>
> Should have tested git head. Compiling git head now to check the current
> status of this issue.
>
>

Git head 36181f98f doesn't compile (x86_64, --enable-checking=all, GCC 
4.5.2):
gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings 
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common 
  -DHAVE_CONFIG_H -I. -I. -I../../../repositories/gcc/gcc 
-I../../../repositories/gcc/gcc/. 
-I../../../repositories/gcc/gcc/../include 
-I../../../repositories/gcc/gcc/../libcpp/include 
-I../../../repositories/gcc/gcc/../libdecnumber 
-I../../../repositories/gcc/gcc/../libdecnumber/bid -I../libdecnumber 
  ../../../repositories/gcc/gcc/fold-const.c -o fold-const.o
../../../repositories/gcc/gcc/fold-const.c: In function 
‘fold_overflow_warning’:
../../../repositories/gcc/gcc/fold-const.c:326:5: warning: format not a 
string literal and no format arguments
../../../repositories/gcc/gcc/fold-const.c: In function 
‘fold_checksum_tree’:
../../../repositories/gcc/gcc/fold-const.c:13803:3: error: invalid 
application of ‘sizeof’ to incomplete type ‘struct tree_type’

-- 
PMatos

Re: Volatile qualification on pointer and data

[Paulo J. Matos]

On 22/09/11 22:15, Richard Guenther wrote:
>
> Btw, I think this is an old bug that has been resolved.  Did you make sure to
> test a recent 4.6 branch snapshot or svn head?
>

My hopes were high but unfortunately it is not fixed yet.
git head 36181f98 still generates the same unexpected code.

Cheers,
-- 
PMatos

Re: Volatile qualification on pointer and data

[Georg-Johann Lay]

David Brown schrieb:
> On 21/09/2011 15:57, Ian Lance Taylor wrote:
> 
>> David Brown<david@westcontrol.com>  writes:
>>
>>> On 21/09/2011 10:21, Paulo J. Matos wrote:
>>>
>>>> On 21/09/11 08:03, David Brown wrote:
>>>>
>>>>> 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.
>>>>
>>>> But since I am accessing the data through the pointer and the pointer
>>>> qualifies the data as volatile, shouldn't the compiler avoid this kind
>>>> of optimization for reads through the pointer?
>>>
>>> My thought is that the nature of "foo" is independent of how it is
>>> accessed.  On the other hand, some uses of a variable will affect its
>>> implementation - if you take the address of "foo" and pass that on to
>>> an external function or data, then the compiler would have to generate
>>> "foo" in memory (but in read-only memory, and it can still assume its
>>> value does not change).  So I am not sure what the "correct" behaviour
>>> is here - I merely ask the question.
>>>
>>> Fortunately, this situation is not going to occur in real code.
>>
>> I think your description is supported by the standard.  However, I also
>> think that gcc should endeavor to fully honor the volatile qualifier in
>> all cases, because that is least surprising to the programmer.  This is
>> not a case where we should let optimization override the programmer's
>> desire; by using volatile, the programmer has explicitly told us that
>> they do not want any optimization to occur.

ACK.

> That makes sense - the principle of least surprise.  And since this 
> situation would not occur in real code (at least, not code that is 
> expected to do something useful other than test the compiler's code 
> generation), there is no harm in making sub-optimal object code.
> 
> Are there any warning flags for "programmer doing something technically 
> legal but logically daft", that could be triggered by such cases? :-)

The combination of const and volatile can be reasonable in real world code.

One example is a special function register (SFR) that is read-only but 
can be altered by hardware.

Second example is a lookup table that can be changed after building the 
software, e.g. you have some calibration data that has to be drawn from 
the environment (drift of sensors, inductivity of motor windings, offset 
of actors, etc).  In such a case you want to read the data from the 
lookup table in, say, .rodata.  By no means you want the compiler to 
insert/propagate known values from the lookup table to immediate 
operands in instructions.  That's exacly what "const volatile" does.

Johann

Re: Volatile qualification on pointer and data

[David Brown]

On 21/09/2011 20:50, Georg-Johann Lay wrote:
> David Brown schrieb:
>> On 21/09/2011 15:57, Ian Lance Taylor wrote:
>>
>>> David Brown<david@westcontrol.com> writes:
>>>
>>>> On 21/09/2011 10:21, Paulo J. Matos wrote:
>>>>
>>>>> On 21/09/11 08:03, David Brown wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> But since I am accessing the data through the pointer and the pointer
>>>>> qualifies the data as volatile, shouldn't the compiler avoid this kind
>>>>> of optimization for reads through the pointer?
>>>>
>>>> My thought is that the nature of "foo" is independent of how it is
>>>> accessed. On the other hand, some uses of a variable will affect its
>>>> implementation - if you take the address of "foo" and pass that on to
>>>> an external function or data, then the compiler would have to generate
>>>> "foo" in memory (but in read-only memory, and it can still assume its
>>>> value does not change). So I am not sure what the "correct" behaviour
>>>> is here - I merely ask the question.
>>>>
>>>> Fortunately, this situation is not going to occur in real code.
>>>
>>> I think your description is supported by the standard. However, I also
>>> think that gcc should endeavor to fully honor the volatile qualifier in
>>> all cases, because that is least surprising to the programmer. This is
>>> not a case where we should let optimization override the programmer's
>>> desire; by using volatile, the programmer has explicitly told us that
>>> they do not want any optimization to occur.
>
> ACK.
>
>> That makes sense - the principle of least surprise. And since this
>> situation would not occur in real code (at least, not code that is
>> expected to do something useful other than test the compiler's code
>> generation), there is no harm in making sub-optimal object code.
>>
>> Are there any warning flags for "programmer doing something
>> technically legal but logically daft", that could be triggered by such
>> cases? :-)
>
> The combination of const and volatile can be reasonable in real world code.
>
> One example is a special function register (SFR) that is read-only but
> can be altered by hardware.
>

That is /very/ different - you are talking about an "extern volatile 
const uint8_t readOnlySFR" declaration, or something effectively like:

#define readOnlySFR (*(volatile const uint8_t *) 0x1234)

Either way, what you are telling the compiler is that this item is 
"volatile", and may change it's value unbeknownst to the compiler, and 
that is "const", meaning that /your/ code may not change its value. 
That's fine, and consistent.  It might sound strange at first - many 
people think "const" means the data is constant and cannot change, when 
in fact C has its one peculiar meaning for "const".

What can't make sense is a /static/ "volatile const" which is /defined/ 
locally, rather than just declared.

> Second example is a lookup table that can be changed after building the
> software, e.g. you have some calibration data that has to be drawn from
> the environment (drift of sensors, inductivity of motor windings, offset
> of actors, etc). In such a case you want to read the data from the
> lookup table in, say, .rodata. By no means you want the compiler to
> insert/propagate known values from the lookup table to immediate
> operands in instructions. That's exacly what "const volatile" does.
>

Again, you are talking about a "volatile const" declaration of data that 
is defined externally, and that's okay.

Also note that in this case the local static const data is not volatile 
- it is only accessed as a volatile through a pointer cast.

Re: Volatile qualification on pointer and data

[John Regehr]

> What can't make sense is a /static/ "volatile const" which is /defined/ 
> locally, rather than just declared.

The code in question sounds well-defined (but probably poor style) to me.

It is never OK to access a qualified object through an unqualified 
pointer, but my understanding is that accessing an unqualified object 
through a qualified pointer is well-defined and that the usual qualifier 
rules apply to that access.

David, is your "can't make sense" backed up by a standard?  There is no 
"lying to the compiler", there is only conforming and non-conforming code.

John

Re: Volatile qualification on pointer and data

[David Brown]

On 24/09/2011 17:09, John Regehr wrote:
>> What can't make sense is a /static/ "volatile const" which is
>> /defined/ locally, rather than just declared.
>
> The code in question sounds well-defined (but probably poor style) to me.
>
> It is never OK to access a qualified object through an unqualified
> pointer, but my understanding is that accessing an unqualified object
> through a qualified pointer is well-defined and that the usual qualifier
> rules apply to that access.
>

That is correct, and it is best to view the qualifiers as qualifying the 
access to the object, rather than the object itself.  Qualifying the 
object just states the minimum qualifiers needed to legally access it.

> David, is your "can't make sense" backed up by a standard? There is no
> "lying to the compiler", there is only conforming and non-conforming code.
>

I don't think the standard has any restrictions on the combinations of 
qualifiers you can have on an object - thus it is legal C to have a 
"static volatile const" object, or to access a "static const" through a 
"volatile" access.  But being legal C does not imply that it makes 
logical sense!

Is it "lying to the compiler"?  Perhaps not, but it is certainly saying 
two different things at the same time - they cannot both make sense, and 
I think the compiler is free to implement whichever of the conflicting 
ideas it wants.

However, I am far from sure here - I am raising the question, not 
answering it.  And while I think the compiler should be allowed to 
generate the optimised code of 4.6 (i.e., the change is not a bug IMHO), 
I fully understand the idea of generating the older, slower, but 
definitely correct code of 4.5.

I am still trying to imagine a real-world use-case for declaring an 
object "static const" and later accessing it as "volatile".

mvh.,

David

Re: Volatile qualification on pointer and data

[David Brown]

On 24/09/2011 17:09, John Regehr wrote:
>> What can't make sense is a /static/ "volatile const" which is
>> /defined/ locally, rather than just declared.
>
> The code in question sounds well-defined (but probably poor style) to me.
>
> It is never OK to access a qualified object through an unqualified
> pointer, but my understanding is that accessing an unqualified object
> through a qualified pointer is well-defined and that the usual qualifier
> rules apply to that access.
>

That is correct, and it is best to view the qualifiers as qualifying the 
access to the object, rather than the object itself.  Qualifying the 
object just states the minimum qualifiers needed to legally access it.

> David, is your "can't make sense" backed up by a standard? There is no
> "lying to the compiler", there is only conforming and non-conforming code.
>

I don't think the standard has any restrictions on the combinations of 
qualifiers you can have on an object - thus it is legal C to have a 
"static volatile const" object, or to access a "static const" through a 
"volatile" access.  But being legal C does not imply that it makes 
logical sense!

Is it "lying to the compiler"?  Perhaps not, but it is certainly saying 
two different things at the same time - they cannot both make sense, and 
I think the compiler is free to implement whichever of the conflicting 
ideas it wants.

However, I am far from sure here - I am raising the question, not 
answering it.  And while I think the compiler should be allowed to 
generate the optimised code of 4.6 (i.e., the change is not a bug IMHO), 
I fully understand the idea of generating the older, slower, but 
definitely correct code of 4.5.

I am still trying to imagine a real-world use-case for declaring an 
object "static const" and later accessing it as "volatile".

mvh.,

David

Re: Volatile qualification on pointer and data

[John Regehr]

> it.  And while I think the compiler should be allowed to generate the 
> optimised code of 4.6 (i.e., the change is not a bug IMHO), I fully 
> understand the idea of generating the older, slower, but definitely correct 
> code of 4.5.

My understanding is that the standard mandates the old behavior, so 4.6 is 
in error.

> I am still trying to imagine a real-world use-case for declaring an object 
> "static const" and later accessing it as "volatile".

Yeah, it would seem far clearer to declare it as static const volatile in 
the first place.

I've done a bunch of automated testing of GCC's implementation of 
volatile.  None of that testing would have exposed this bug because we 
only count acceses to objects declared as volatile.

I've come to the conclusion that "volatile" is a language design error. 
It complicates the compiler implementation and has confusing, 
underspecified semantics. If you want to force a load or store, an 
explicit function call is a clearer way to do it.

John

Re: Volatile qualification on pointer and data

[David Brown]

On 24/09/2011 18:25, John Regehr wrote:
>> it. And while I think the compiler should be allowed to generate the
>> optimised code of 4.6 (i.e., the change is not a bug IMHO), I fully
>> understand the idea of generating the older, slower, but definitely
>> correct code of 4.5.
>
> My understanding is that the standard mandates the old behavior, so 4.6
> is in error.
>
>> I am still trying to imagine a real-world use-case for declaring an
>> object "static const" and later accessing it as "volatile".
>
> Yeah, it would seem far clearer to declare it as static const volatile
> in the first place.
>

I still can't think why one would ever want such a thing.

There is a big difference between defining an object as "const", and 
merely declaring it as const or accessing it as const.  When you access 
it as const, you are saying "/I/ won't change the object with this 
access".  When you declare an object as const (such as an extern 
object), you are saying "/I/ won't change this object".  When you 
/define/ an object as const, as you do with a "static const", you are 
saying "this object is constant.  It will never change value - you (the 
toolchain) can safely place it in read-only memory that cannot ever 
change value".

And then you make it volatile, telling the compiler "this object might 
change unexpectedly, or use values written to it unexpectedly".

If someone could explain to me how this could have real-world usage, I 
think it would be easier for me (and others) to be sure of what it 
really means.

> I've done a bunch of automated testing of GCC's implementation of
> volatile. None of that testing would have exposed this bug because we
> only count acceses to objects declared as volatile.
>
> I've come to the conclusion that "volatile" is a language design error.
> It complicates the compiler implementation and has confusing,
> underspecified semantics. If you want to force a load or store, an
> explicit function call is a clearer way to do it.
>

I agree on that, as I think do many - "volatile" is not defined clearly 
enough.  It is also not flexible enough for optimal code generation in 
many cases when it is used regularly, such as for embedded programming. 
  There it is not uncommon to want something that has volatile write 
accesses, but does not need volatile read accesses.  It gets seriously 
messy when you combine "volatile" with bitfields - the standards are 
(AFAIK) unclear, and implementations of volatile bitfields vary wildly. 
  And since "volatile" does not have any interaction with things like 
cpu instruction re-ordering, speculative accesses, write buffering and 
combining, caches, etc., or with any operating system specific 
interactions, it often doesn't do what the user thinks it will do.

However, it is currently the only tool we have in C.

Re: Volatile qualification on pointer and data

[Andreas Schwab]

David Brown <david@westcontrol.com> writes:

> There is a big difference between defining an object as "const", and
> merely declaring it as const or accessing it as const.  When you access it
> as const, you are saying "/I/ won't change the object with this access".
> When you declare an object as const (such as an extern object), you are
> saying "/I/ won't change this object".  When you /define/ an object as
> const, as you do with a "static const", you are saying "this object is
> constant.  It will never change value - you (the toolchain) can safely
> place it in read-only memory that cannot ever change value".

You are interpreting too much into const here.  The C standard says in
footnote 112: "The implementation may place a const object that is not
volatile in a read-only region of storage."  Note the use of "not
volatile".  But in any case this is not part of the C standard: it's
only a footnote.

> And then you make it volatile, telling the compiler "this object might
> change unexpectedly, or use values written to it unexpectedly".
>
> If someone could explain to me how this could have real-world usage, I
> think it would be easier for me (and others) to be sure of what it really
> means.

It's an object that is never written to, but may change unexpectedly.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Volatile qualification on pointer and data

[David Brown]

On 25/09/11 16:16, Andreas Schwab wrote:
> David Brown<david@westcontrol.com>  writes:
>
>> There is a big difference between defining an object as "const", and
>> merely declaring it as const or accessing it as const.  When you access it
>> as const, you are saying "/I/ won't change the object with this access".
>> When you declare an object as const (such as an extern object), you are
>> saying "/I/ won't change this object".  When you /define/ an object as
>> const, as you do with a "static const", you are saying "this object is
>> constant.  It will never change value - you (the toolchain) can safely
>> place it in read-only memory that cannot ever change value".
>
> You are interpreting too much into const here.  The C standard says in
> footnote 112: "The implementation may place a const object that is not
> volatile in a read-only region of storage."  Note the use of "not
> volatile".  But in any case this is not part of the C standard: it's
> only a footnote.
>

I stand corrected on that point - thanks.

>> And then you make it volatile, telling the compiler "this object might
>> change unexpectedly, or use values written to it unexpectedly".
>>
>> If someone could explain to me how this could have real-world usage, I
>> think it would be easier for me (and others) to be sure of what it really
>> means.
>
> It's an object that is never written to, but may change unexpectedly.
>

Again, I can see that "volatile const" is useful for declaring external 
objects (or accesses to objects), but not when the address of the object 
is allocated by the toolchain (as is the case here with a "static const 
volatile".

The only scenario I have heard where this might be useful is for 
debugging - making what is normally a "static const" volatile so that 
it's value can be changed with a debugger.  Personally, I think that in 
such cases you would be better removing the "const" when you add the 
"volatile".

Re: Volatile qualification on pointer and data

[David Brown]

On 25/09/11 16:16, Andreas Schwab wrote:
> David Brown<david@westcontrol.com>  writes:
>
>> There is a big difference between defining an object as "const", and
>> merely declaring it as const or accessing it as const.  When you access it
>> as const, you are saying "/I/ won't change the object with this access".
>> When you declare an object as const (such as an extern object), you are
>> saying "/I/ won't change this object".  When you /define/ an object as
>> const, as you do with a "static const", you are saying "this object is
>> constant.  It will never change value - you (the toolchain) can safely
>> place it in read-only memory that cannot ever change value".
>
> You are interpreting too much into const here.  The C standard says in
> footnote 112: "The implementation may place a const object that is not
> volatile in a read-only region of storage."  Note the use of "not
> volatile".  But in any case this is not part of the C standard: it's
> only a footnote.
>

I stand corrected on that point - thanks.

>> And then you make it volatile, telling the compiler "this object might
>> change unexpectedly, or use values written to it unexpectedly".
>>
>> If someone could explain to me how this could have real-world usage, I
>> think it would be easier for me (and others) to be sure of what it really
>> means.
>
> It's an object that is never written to, but may change unexpectedly.
>

Again, I can see that "volatile const" is useful for declaring external 
objects (or accesses to objects), but not when the address of the object 
is allocated by the toolchain (as is the case here with a "static const 
volatile".

The only scenario I have heard where this might be useful is for 
debugging - making what is normally a "static const" volatile so that 
it's value can be changed with a debugger.  Personally, I think that in 
such cases you would be better removing the "const" when you add the 
"volatile".

Re: Volatile qualification on pointer and data

[Dave Korn]

On 25/09/2011 13:56, David Brown wrote:

> There is a big difference between defining an object as "const", and
> merely declaring it as const or accessing it as const.  When you access
> it as const, you are saying "/I/ won't change the object with this
> access".  When you declare an object as const (such as an extern
> object), you are saying "/I/ won't change this object".  When you
> /define/ an object as const, as you do with a "static const", you are
> saying "this object is constant.  It will never change value - you (the
> toolchain) can safely place it in read-only memory that cannot ever
> change value".
> 
> And then you make it volatile, telling the compiler "this object might
> change unexpectedly, or use values written to it unexpectedly".
> 
> If someone could explain to me how this could have real-world usage, I
> think it would be easier for me (and others) to be sure of what it
> really means.

  Just because it's static doesn't mean the address can't escape:

/* May read or write to dest, according to direction flag.  */
extern void start_dma_xfer (void *dest, unsigned int size, bool direction,
                            uint64_t bus_addr);

/* We don't want to change this ourselves, and nor do we want the symbol
   to be externally visible.  */
static const volatile char *dma_buffer[BUFFERSIZE];

[ ... later, in a function ... ]

  start_dma_transfer (&dma_buffer[0], size, DIRECTION_DMA_TO_MEMORY, devaddr);


  A bit contrived perhaps, but start_dma_transfer (or some similar function)
might be part of the OS or written in assembly and so necessarily C-type-safe.

    cheers,
      DaveK

Re: Volatile qualification on pointer and data

[David Brown]

On 25/09/11 17:15, Dave Korn wrote:
> On 25/09/2011 13:56, David Brown wrote:
>
>> There is a big difference between defining an object as "const", and
>> merely declaring it as const or accessing it as const.  When you access
>> it as const, you are saying "/I/ won't change the object with this
>> access".  When you declare an object as const (such as an extern
>> object), you are saying "/I/ won't change this object".  When you
>> /define/ an object as const, as you do with a "static const", you are
>> saying "this object is constant.  It will never change value - you (the
>> toolchain) can safely place it in read-only memory that cannot ever
>> change value".
>>
>> And then you make it volatile, telling the compiler "this object might
>> change unexpectedly, or use values written to it unexpectedly".
>>
>> If someone could explain to me how this could have real-world usage, I
>> think it would be easier for me (and others) to be sure of what it
>> really means.
>
>    Just because it's static doesn't mean the address can't escape:
>
> /* May read or write to dest, according to direction flag.  */
> extern void start_dma_xfer (void *dest, unsigned int size, bool direction,
>                              uint64_t bus_addr);
>
> /* We don't want to change this ourselves, and nor do we want the symbol
>     to be externally visible.  */
> static const volatile char *dma_buffer[BUFFERSIZE];
>
> [ ... later, in a function ... ]
>
>    start_dma_transfer (&dma_buffer[0], size, DIRECTION_DMA_TO_MEMORY, devaddr);
>
>
>    A bit contrived perhaps, but start_dma_transfer (or some similar function)
> might be part of the OS or written in assembly and so necessarily C-type-safe.
>
>      cheers,
>        DaveK
>
>

I can see that as a possibility, though to me it reads as bad style. 
I'm aware that taking the address of a static object can let it 
"escape", and mentioned that possibility in other posts - it will 
certainly force the object to be created in memory.  However, I just 
don't see why a buffer like this would be defined "const" - it's not 
constant, so what are you trying to achieve by saying "const"?

To answer that, you have to first say /why/ anyone would use the "const" 
qualifier in the first place.  There are five reasons I can think of. 
First, you have compatibility with other code and types.  Then you have 
error-checking - if you know you will not change an object, you make it 
"const" to let the compiler check that you haven't changed it by 
mistake.  Then there is optimisation - by telling the compiler that the 
object won't change value, you let it generate better code (such as 
using "static const" instead of old-fashioned "#define" or enum 
constants).  Next, you define objects as "const" to let the toolchain 
place the object in read-only memory - this is very important for small 
embedded systems running from flash memory.  Finally, you use "const" as 
documentation - you use it when it makes it clearer what the code is 
doing, why it is doing it, or how it is doing it.

So what advantages would there be in declaring a volatile buffer like 
this to be "const"?  At best, you are helping the compiler check that 
you don't accidentally write to it in your own code.  It is dangerous 
regarding optimisation - you definitely don't want the compiler to 
optimise the buffer, yet this whole discussion started because some 
compilers /do/ optimise such code (rightly or wrongly).  You don't want 
the toolchain to put it read-only memory (as noted by another poster, 
doing so would be against the standards - but toolchain writers are not 
infallible, and weird corner-cases like this are where mistakes are less 
likely to be spotted and fixed).  So does the "const" make the program 
clearer to the code writer, and other readers?  I would say it has the 
opposite effect, and leaves a reader wondering what it is supposed to 
mean - the buffer is clearly not meant to be constant, so why is it 
declared "const"?

When I write code, I almost always define objects as "const" when 
possible.  But in this case there would be no doubt in my mind - that 
buffer is /not/ constant, and should not be defined as "const" even if 
it happened to compile and run correctly.

I am aware that this is a stylistic choice.  But I don't see it as good 
programming to push boundaries with "risky" code that might or might not 
work depending on how the compiler writers interpreted the standards - 
especially when it makes the code less clear to human readers.

Re: Volatile qualification on pointer and data

[David Brown]

On 25/09/11 17:15, Dave Korn wrote:
> On 25/09/2011 13:56, David Brown wrote:
>
>> There is a big difference between defining an object as "const", and
>> merely declaring it as const or accessing it as const.  When you access
>> it as const, you are saying "/I/ won't change the object with this
>> access".  When you declare an object as const (such as an extern
>> object), you are saying "/I/ won't change this object".  When you
>> /define/ an object as const, as you do with a "static const", you are
>> saying "this object is constant.  It will never change value - you (the
>> toolchain) can safely place it in read-only memory that cannot ever
>> change value".
>>
>> And then you make it volatile, telling the compiler "this object might
>> change unexpectedly, or use values written to it unexpectedly".
>>
>> If someone could explain to me how this could have real-world usage, I
>> think it would be easier for me (and others) to be sure of what it
>> really means.
>
>    Just because it's static doesn't mean the address can't escape:
>
> /* May read or write to dest, according to direction flag.  */
> extern void start_dma_xfer (void *dest, unsigned int size, bool direction,
>                              uint64_t bus_addr);
>
> /* We don't want to change this ourselves, and nor do we want the symbol
>     to be externally visible.  */
> static const volatile char *dma_buffer[BUFFERSIZE];
>
> [ ... later, in a function ... ]
>
>    start_dma_transfer (&dma_buffer[0], size, DIRECTION_DMA_TO_MEMORY, devaddr);
>
>
>    A bit contrived perhaps, but start_dma_transfer (or some similar function)
> might be part of the OS or written in assembly and so necessarily C-type-safe.
>
>      cheers,
>        DaveK
>
>

I can see that as a possibility, though to me it reads as bad style. 
I'm aware that taking the address of a static object can let it 
"escape", and mentioned that possibility in other posts - it will 
certainly force the object to be created in memory.  However, I just 
don't see why a buffer like this would be defined "const" - it's not 
constant, so what are you trying to achieve by saying "const"?

To answer that, you have to first say /why/ anyone would use the "const" 
qualifier in the first place.  There are five reasons I can think of. 
First, you have compatibility with other code and types.  Then you have 
error-checking - if you know you will not change an object, you make it 
"const" to let the compiler check that you haven't changed it by 
mistake.  Then there is optimisation - by telling the compiler that the 
object won't change value, you let it generate better code (such as 
using "static const" instead of old-fashioned "#define" or enum 
constants).  Next, you define objects as "const" to let the toolchain 
place the object in read-only memory - this is very important for small 
embedded systems running from flash memory.  Finally, you use "const" as 
documentation - you use it when it makes it clearer what the code is 
doing, why it is doing it, or how it is doing it.

So what advantages would there be in declaring a volatile buffer like 
this to be "const"?  At best, you are helping the compiler check that 
you don't accidentally write to it in your own code.  It is dangerous 
regarding optimisation - you definitely don't want the compiler to 
optimise the buffer, yet this whole discussion started because some 
compilers /do/ optimise such code (rightly or wrongly).  You don't want 
the toolchain to put it read-only memory (as noted by another poster, 
doing so would be against the standards - but toolchain writers are not 
infallible, and weird corner-cases like this are where mistakes are less 
likely to be spotted and fixed).  So does the "const" make the program 
clearer to the code writer, and other readers?  I would say it has the 
opposite effect, and leaves a reader wondering what it is supposed to 
mean - the buffer is clearly not meant to be constant, so why is it 
declared "const"?

When I write code, I almost always define objects as "const" when 
possible.  But in this case there would be no doubt in my mind - that 
buffer is /not/ constant, and should not be defined as "const" even if 
it happened to compile and run correctly.

I am aware that this is a stylistic choice.  But I don't see it as good 
programming to push boundaries with "risky" code that might or might not 
work depending on how the compiler writers interpreted the standards - 
especially when it makes the code less clear to human readers.

Re: Volatile qualification on pointer and data

[Miles Bader]

David Brown <david.brown@hesbynett.no> writes:
> So what advantages would there be in declaring a volatile buffer like
> this to be "const"?  At best, you are helping the compiler check that
> you don't accidentally write to it in your own code.

That's actually pretty handy tho...

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: Volatile qualification on pointer and data

[David Brown]

On 26/09/2011 02:37, Miles Bader wrote:
> David Brown<david.brown@hesbynett.no>  writes:
>> So what advantages would there be in declaring a volatile buffer like
>> this to be "const"?  At best, you are helping the compiler check that
>> you don't accidentally write to it in your own code.
>
> That's actually pretty handy tho...
>

Oh, I'm all in favour of static error checking - use const pointers 
where possible, and there are not many of gcc's warning flags that I 
don't use.  But I'd weigh code clarity above error checking in this 
case, especially since it is very unlikely that you'd write code that 
accidentally wrote to the buffer.

Re: Volatile qualification on pointer and data

[David Brown]

On 26/09/2011 02:37, Miles Bader wrote:
> David Brown<david.brown@hesbynett.no>  writes:
>> So what advantages would there be in declaring a volatile buffer like
>> this to be "const"?  At best, you are helping the compiler check that
>> you don't accidentally write to it in your own code.
>
> That's actually pretty handy tho...
>

Oh, I'm all in favour of static error checking - use const pointers 
where possible, and there are not many of gcc's warning flags that I 
don't use.  But I'd weigh code clarity above error checking in this 
case, especially since it is very unlikely that you'd write code that 
accidentally wrote to the buffer.

Re: Volatile qualification on pointer and data

[Paulo J. Matos]

On 20/09/11 17:35, Ian Lance Taylor wrote:
> I agree that this looks like a bug.  Please file a bug report marked as
> a regression.
>
> Ian
>

Thanks. Reported as 50472 even though I am just reading Davids post and 
he is convincing me that this might not be a bug after all, however, it 
is still behaving differently than GCC45 but you might then consider it 
a feature instead of a bug.

-- 
PMatos