Re: volatile semantics

Re: volatile semantics

[Paul Schlie]

> I did see Ian's summary,
>
>  http://gcc.gnu.org/ml/gcc/2005-07/msg00714.html
>
> wherein he ascribed the semantics of the volatile qualifier to the
> access, and not to the object.  I agree with his description completely,
> as I believe it embodies the intuition that C programmers have used
> wrt these qualifiers since forever.
>
> So the answers to the "deleteable" questions above are no, no, yes.
> 
> And it's probably a one-line bug in our "can this cast be removed"
> function.

- or even more consistently: simply warn, and treat as specified in all
  cases. (as there's no value to exceptions otherwise)

Re: volatile semantics

[Olivier Galibert]

On Sun, Jul 17, 2005 at 11:56:46AM -0700, Geoffrey Keating wrote:
> "D. Hugh Redelmeier" <hugh@mimosa.com> writes:
> > An object that has volatile-qualified type may be modified in ways
> > unknown to the implementation or have other unknown side
> > effects. Therefore any expression referring to such an object shall be
> > evaluated strictly according to the rules of the abstract machine
> 
> The word you missed is 'Therefore'.  If an implementation can
> determine that an object is not modified unknown to the
> implementation, the implementation need not evaluate it strictly
> according to the rules of the abstract machine.

I don't read it that way.  I read it as "whatever the implementation
may think, it can _not_ determine whether the object may be
modified/has side effects unknown to it".

  OG.

Re: volatile semantics

[Mike Stump]

On Friday, July 22, 2005, at 06:28 PM, Geoff Keating wrote:
> I am discussing here only with what GCC *could* do, and still be 
> standards-conforming.  What it *should* do is a different > conversation.

You will have to explain the benefits to me of having discussions on 
this list of discussing the limits of how we can mis-read the standard. 
  I just don't see the benefits.  I think the place for such discussions 
would be on an standards body list dedicating to word smithing the 
standards into such a shape to to be impervious to such attempts.

I'd rather discuss what is best for our users, now, and in the future, 
how we'd like to see the standard evolve, the ways in which the 
standard language is wrong and how we should interpret it and so on...

To the unaided eye, you seem to be telling us how gcc should behave, if 
that isn't your intention, could you please start with how you think 
gcc should behave, then launch into why how that behavior can be seen 
to conflict with the standard, if the standard is read in a particular 
way, that would help us understand your position better.

Re: volatile semantics

[Paul Schlie]

(sorry, with intended statement this time)

> From: Geoff Keating <geoffk@geoffk.org>
> On 22/07/2005, at 7:15 PM, Paul Schlie wrote:
> 
>>> Geoffrey Keating writes:
> 
>>> without 'volatile', then this object cannot be modified unknown to
>>> the implementation, even if someone also writes '(*(volatile int *)&i)
>>> = 1'.
>> 
>> - merely means: treat the object being referenced as volatile
>> qualified int object (as the standard specifies, although it may result
>> in an  undefined behavior, nothing more or less; as although the object
>> may have not been initially declared as being volatile, the program
>> within the context of this particular references has asserted that it
>> must be treated as such, thereby implying it's value must be assigned,
>> and/or presumed to have been possibly modified beyond the logical view
>> of the program).
> 
> It doesn't imply that.  All it implies is that *from this access* the
> compiler cannot assume that the object is not "modified in ways
> unknown to the implementation".  From other accesses, including from
> the original declaration (and its initializer if any), the
> implementation may be able to make that deduction. If, and only if,
> the implementation can make that deduction, then it can perform
> optimizations.

- It can not, C's object's reference access model is based upon an
  object's classification within the context of it's specified access.
  (as it's lvalue "locator value" is specified as defining the object
  being referenced.)

>  In this example:
> 
> int i = 0;
> while (*(volatile int *)&i == 0) ;
> 
> then the implementation can make that assumption, and optimise the
> loop into an infinite loop that does not test 'i', because the '= 0;'
> performs a store to a non-volatile object 'i' which therefore cannot
> be modified in ways unknown to the implementation and therefore will
> always be zero.

- It can not, as the object being referenced is unambiguously specified
  as a volatile object, i.e. within the context of this reference it
  must assume that it's state may be affected by forces beyond the
  scope of the logical program by definition. (Which may or may not be
  consistent with it's previous declarations; where if not, may or may
  not affect the logical integrity of an implementation's volatile object
  allocation and/or semantic presumptions; in which case if deducible, a
  warning without any attempt to alter the behavior/assertions specified
  would likely be most useful.)

Correspondingly for example:

- all qualifier based behavior/assertions should be similarly scoped.

- and further, pointers should be simultaneously included in all alias
  sets that their references are cast to within their respective scopes
  without needing to explicitly define them as a union of referenced types,
  as C's object reference based model implies they should ideally safely be.

Overall, someone should really re-think and hopefully eliminate GCC's
predisposition to go seemingly out of its way to identify opportunities
to obfuscate compiled code behaviors based on the justification that it's
enabled to do so for undefined behaviors, as all such optimizations will
only truly result in unexpected behaviors, without benefit to anyone;
although warning of their presence is likely universally useful.

Re: volatile semantics

[Paul Schlie]

> From: Geoff Keating <geoffk@geoffk.org>
> On 22/07/2005, at 7:15 PM, Paul Schlie wrote:
> 
>>> Geoffrey Keating writes:
> 
>>> without 'volatile', then this object cannot be modified unknown to
>>> the implementation, even if someone also writes '(*(volatile int *)&i)
>>> = 1'.
>> 
>> - merely means: treat the object being referenced as volatile
>> qualified int object (as the standard specifies, although it may result
>> in an  undefined behavior, nothing more or less; as although the object
>> may have not been initially declared as being volatile, the program
>> within the context of this particular references has asserted that it
>> must be treated as such, thereby implying it's value must be assigned,
>> and/or presumed to have been possibly modified beyond the logical view
>> of the program).
> 
> It doesn't imply that.  All it implies is that *from this access* the
> compiler cannot assume that the object is not "modified in ways
> unknown to the implementation".  From other accesses, including from
> the original declaration (and its initializer if any), the
> implementation may be able to make that deduction. If, and only if,
> the implementation can make that deduction, then it can perform
> optimizations.

- It can not, C's object's reference access model is based upon an
  object's classification within the context of it's specified access.
  (as it's lvalue "locator value" is specified as defining the object
  being referenced.)

>  In this example:
> 
> int i = 0;
> while (*(volatile int *)&i == 0) ;
> 
> then the implementation can make that assumption, and optimise the
> loop into an infinite loop that does not test 'i', because the '= 0;'
> performs a store to a non-volatile object 'i' which therefore cannot
> be modified in ways unknown to the implementation and therefore will
> always be zero.

- It can not, as the object being referenced is unambiguously specified
  as a volatile object, i.e. within the context of that reference may
  not assume that it's value may not be affected by forces beyond the
  scope of the logical program by definition. (Which may or may not be
  consistent with it's previous declarations; where if not, may or may
  not affect the logical integrity of an implementation's volatile object
  allocation and/or semantic presumptions; in which case if deducible, a
  warning without any attempt to alter the behavior/assertions specified
  would likely be most useful.)

Correspondingly for example:

- all qualifier based behavior/assertions should be similarly scoped.

- and further, pointers should be simultaneously included in all alias
  sets that their references are cast to within their respective scopes
  without needing to explicitly define them as a union of referenced types,
  as C's object reference based model implies they should ideally safely be.

Overall, someone should really re-think and hopefully eliminate GCC's
predisposition to go seemingly out of its way to identify opportunities
to obfuscate compiled code behaviors based on the justification that it's
enabled to do so for undefined behaviors, as all such optimizations will
only truly result in unexpected behaviors, without benefit to anyone;
although warning of their presence is likely universally useful.

Re: volatile semantics

[Geoff Keating]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]


On 22/07/2005, at 7:15 PM, Paul Schlie wrote:

>> Geoffrey Keating writes:

>> without 'volatile', then this object cannot be modified unknown to  
>> the
>> implementation, even if someone also writes '(*(volatile int *)&i)  
>> = 1'.
>>
>
> - merely means: treat the object being referenced as volatile  
> qualified int
>   object (as the standard specifies, although it may result in an  
> undefined
>   behavior, nothing more or less; as although the object may have  
> not been
>   initially declared as being volatile, the program within the  
> context of
>   this particular references has asserted that it must be treated  
> as such,
>   thereby implying it's value must be assigned, and/or presumed to  
> have been
>   possibly modified beyond the logical view of the program).

It doesn't imply that.  All it implies is that *from this access* the  
compiler cannot assume that the object is not "modified in ways  
unknown to the implementation".  From other accesses, including from  
the original declaration (and its initializer if any), the  
implementation may be able to make that deduction.  If, and only if,  
the implementation can make that deduction, then it can perform  
optimizations.  In this example:

int i = 0;
while (*(volatile int *)&i == 0) ;

then the implementation can make that assumption, and optimise the  
loop into an infinite loop that does not test 'i', because the '= 0;'  
performs a store to a non-volatile object 'i' which therefore cannot  
be modified in ways unknown to the implementation and therefore will  
always be zero.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2410 bytes --]

Re: volatile semantics

[Geoff Keating]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]


On 22/07/2005, at 7:57 PM, Gabriel Dos Reis wrote:

> There is a "semantics of access".  It is implementation-defined.

I think you're thinking of "what constitutes an access", which is  
implementation-defined, but is not the same of the semantics of an  
access.

> The standard describes things like side effect and such in terms of  
> *access*.

That's true, but this actually makes the model less useful, not  
more.  There is no requirement on the implementation that it actually  
perform any side effects if they are not needed.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2410 bytes --]

Re: volatile semantics

[Ian Lance Taylor]

Geoff Keating <geoffk@geoffk.org> writes:

> This is part of what I meant by saying that your model isn't a match
> for the model in the standard.  Your model had semantics attached to
> the access.

Despite evident appearances, I wasn't trying to make an argument from
the standard.  I was trying to describe the way I think people expect
gcc to behave, and the way I think gcc should behave.  If I had been
trying to make an argument from the standard, I would have provided
citations for my description of volatile.  I'm only moderately
interested in arguments about the standard.  I'm quite a bit more
interested in arguments about what gcc should do.

Nevertheless, I note that my pragmatic view appears to agree with the
standard-based one D. Hugh Redelmeier passed on from Henry Spencer
here:
    http://gcc.gnu.org/ml/gcc/2005-07/msg00664.html

So I feel fairly comfortable with my position.

Ian

Re: volatile semantics

[Gabriel Dos Reis]

Geoff Keating <geoffk@geoffk.org> writes:

| On 22/07/2005, at 4:33 PM, Ian Lance Taylor wrote:
| 
| > Geoffrey Keating <geoffk@geoffk.org> writes:
| >
| >> Although I can see that this is how you might think about the
| >> semantics of 'const' and 'volatile', I don't think they're an exact
| >> match for the model in the standard.  In fact, I think you could
| >> exchange the words 'const' and 'volatile' in the above and they would
| >> be equally accurate.
| >>
| >
| > Sure, and I think my ultimate point would still be accurate: gcc
| > should handle the access using the qualification of the pointer, not
| > of the underlying object.  The rest of the argument is just
| > motivation.
| 
| By "equally accurate", I also meant "equally inaccurate".
| 
| You've successfully argued that 'const' and 'volatile' are the same
| in lots of ways; but 'const' and 'volatile' do differ.  In order to
| be successful in this argument, you need to argue that the
| differences don't matter.
| 
| And, unfortunately, the differences *do* matter.  The standard does
| not say "any expression referring to a volatile-qualified type must
| be evaluated strictly according to the rules of the abstract
| machine".  What it says is that "An object that has volatile
| qualified type may be modified in ways unknown to the implementation"
| and then lists some of the consequences of an object being modifiable
| in that way.  So there are no "semantics of the access"; the
| semantics attach to the object.

I disagree with statement.  There is a "semantics of access".  It is
implementation-defined.

| This is part of what I meant by saying that your model isn't a match
| for the model in the standard.  Your model had semantics attached to
| the access.

On the contrary, I find his moel most faithful than the interpretation
you offer.  The standard describes things like side effect and such in
terms of *access*.  

-- Gaby

Re: volatile semantics

[Paul Schlie]

> Geoffrey Keating writes:
>
> int i;

- merely means: allocate and treat all references to the object as
  referencing an unqualified int object, unless re-qualified within a
  more local scope.

> without 'volatile', then this object cannot be modified unknown to the
> implementation, even if someone also writes '(*(volatile int *)&i) = 1'.

- merely means: treat the object being referenced as volatile qualified int
  object (as the standard specifies, although it may result in an undefined
  behavior, nothing more or less; as although the object may have not been
  initially declared as being volatile, the program within the context of
  this particular references has asserted that it must be treated as such,
  thereby implying it's value must be assigned, and/or presumed to have been
  possibly modified beyond the logical view of the program).

  const, volatile, and restrict are all logically equivalent in this
  regard; regardless of whether or not an object was declared as being
  originally qualified, or subsequently declared as being so within the more
  restricted scope of a function via it's parameter declaration, or single
  reference via a qualified cast.  Where although inconsistent references to
  any single object may result in an undefined behavior, it should be clear
  there's no value in attempting to rationalize any more creative less
  consistent interpretation, as it will be no more correct, and only likely
  unnecessarily complicating to both the implementation and programmer.

Re: volatile semantics

[Geoff Keating]

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]


On 22/07/2005, at 4:33 PM, Ian Lance Taylor wrote:

> Geoffrey Keating <geoffk@geoffk.org> writes:
>
>> Although I can see that this is how you might think about the
>> semantics of 'const' and 'volatile', I don't think they're an exact
>> match for the model in the standard.  In fact, I think you could
>> exchange the words 'const' and 'volatile' in the above and they would
>> be equally accurate.
>>
>
> Sure, and I think my ultimate point would still be accurate: gcc
> should handle the access using the qualification of the pointer, not
> of the underlying object.  The rest of the argument is just
> motivation.

By "equally accurate", I also meant "equally inaccurate".

You've successfully argued that 'const' and 'volatile' are the same  
in lots of ways; but 'const' and 'volatile' do differ.  In order to  
be successful in this argument, you need to argue that the  
differences don't matter.

And, unfortunately, the differences *do* matter.  The standard does  
not say "any expression referring to a volatile-qualified type must  
be evaluated strictly according to the rules of the abstract  
machine".  What it says is that "An object that has volatile  
qualified type may be modified in ways unknown to the implementation"  
and then lists some of the consequences of an object being modifiable  
in that way.  So there are no "semantics of the access"; the  
semantics attach to the object.

This is part of what I meant by saying that your model isn't a match  
for the model in the standard.  Your model had semantics attached to  
the access.

> In fact const and volatile are analogous here.  If you have a
> non-const object, and you attempt to access it with a const-qualified
> pointer, the compiler will apply the semantics of const (i.e., it will
> reject an attempt to modify the object through the pointer).

There are no general differences in semantics of a 'const' access.   
There are only special semantics of an assignment to a 'const' lvalue  
(it's not allowed).  Nor are there any special semantics of a 'const'  
object; in particular, it is not true that a 'const' object cannot  
change, only that it can't be changed from C.  So it's not true that  
const and volatile are analogous here, nor is it true that an access  
to a non-const object with a const-qualified pointer is different to  
accessing it with a non-const-qualified pointer.

I am discussing here only with what GCC *could* do, and still be  
standards-conforming.  What it *should* do is a different conversation.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2410 bytes --]

Re: volatile semantics

[Ian Lance Taylor]

Geoffrey Keating <geoffk@geoffk.org> writes:

> > const is inherently a characteristic of the object.  It applies at
> > definition time.  Casting away const in a reference does not change
> > the definition.  Whether making an assignment through a pointer after
> > casting away const is legal depends upon how the definition of the
> > object pointed to is handled (C99 6.7.3: "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").
> 
> The very next sentence says
> 
> > 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 behaviour is undefined.
> 
> so I don't see how this supports your distinction between 'const' and
> 'volatile'.

I know that sentence is there, but it's irrelevant to the point I was
trying to make.  In the paragraph quoted above I was discussing
objects defined as const.  The issue at hand is about an object which
is not defined as volatile, for which an access is made using a
volatile qualified pointer.

In fact const and volatile are analogous here.  If you have a
non-const object, and you attempt to access it with a const-qualified
pointer, the compiler will apply the semantics of const (i.e., it will
reject an attempt to modify the object through the pointer).
Similarly, I am arguing that if you have a non-volatile object, and
you attempt to access it with a volatile-qualified pointer, the
compiler should apply the semantics of volatile.

> > volatile, on the other hand, is inherently a characteristic of the
> > access, not of the object.  Defining a volatile object does nothing in
> > itself; it merely affects all accesses to the object.  Thus casting to
> > volatile should mean that all uses of the resulting pointer should be
> > done in a volatile fashion--i.e., all reads and writes done precisely
> > as specified by the standard's "abstract machine."  Casting away from
> > volatile means the reverse--there are no restrictions on the use of
> > the object to which the pointer points.
> 
> Although I can see that this is how you might think about the
> semantics of 'const' and 'volatile', I don't think they're an exact
> match for the model in the standard.  In fact, I think you could
> exchange the words 'const' and 'volatile' in the above and they would
> be equally accurate.

Sure, and I think my ultimate point would still be accurate: gcc
should handle the access using the qualification of the pointer, not
of the underlying object.  The rest of the argument is just
motivation.

> The above reminds me of the arguments in physics about the wave or
> particle nature of things.  The answer, of course, is that although
> those are useful models, neither is an exact description of all the
> properties.

The key difference, of course, is that the C language was made up by
humans, and thus to a specific question like this (how should we
handle an access through a volatile-qualified pointer) there either is
an answer already, or we can make one up.  It is not unknowable or
ambiguous or subject to future research, although the answer may be
"the compiler can do as it pleases."

Ian

Re: volatile semantics

[Geoffrey Keating]

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

> 6.3.2.1:  when an object is said to have a particular type, the type is
> specified by the lvalue used to designate the object.  So the lvalue
> having a volatile-qualified type *means* that the object it designates has
> a volatile-qualified type; "has type X" and "is designated by an lvalue of
> type X" are synonymous (!).
> 
> 6.7.3:  any expression referring to an object of volatile-qualified
> type must be evaluated strictly by the rules of the abstract machine,
> although precisely what constitutes an "access" to the object is
> implementation-defined.  (Note, "implementation-defined" behavior is
> required to be well-defined and *documented*.)  So if the reference in
> question is an "access", it must occur where the abstract machine says
> it should.

I think you missed an important word here.  The standard actually
says, in 6.7.3 paragraph 6,

> An object that has volatile-qualified type may be modified in ways
> unknown to the implementation or have other unknown side
> effects. Therefore any expression referring to such an object shall be
> evaluated strictly according to the rules of the abstract machine

The word you missed is 'Therefore'.  If an implementation can
determine that an object is not modified unknown to the
implementation, the implementation need not evaluate it strictly
according to the rules of the abstract machine.

How could an implementation tell such a thing?  Well, the first
sentence is exclusive, it means that only volatile objects may be
modified unknown to the implementation.  If the user has declared

int i;

without 'volatile', then this object cannot be modified unknown to the
implementation, even if someone also writes '(*(volatile int *)&i) =
1'.

Re: volatile semantics

[Geoffrey Keating]

Ian Lance Taylor <ian@airs.com> writes:

> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> > > In other words, we're asked to agree that the type of an object
> > > changes depending on how it is accessed.
> > > For the benefit of readers, only the first sentence of this para is
> > > the language of the standard; the rest isn't.  
> > > 
> > > That an object referred to through a volatile pointer must
> > > "temporarily" be treated as though it were declared volatile is the
> > > crux of this argument. 
> > 
> > Again, you could say the same about const, restrict, or any other
> > qualifier then, making them more or less useless as qualifiers.
> 
> I think there may be a difference.
> 
> const is inherently a characteristic of the object.  It applies at
> definition time.  Casting away const in a reference does not change
> the definition.  Whether making an assignment through a pointer after
> casting away const is legal depends upon how the definition of the
> object pointed to is handled (C99 6.7.3: "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").

The very next sentence says

> 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 behaviour is undefined.

so I don't see how this supports your distinction between 'const' and
'volatile'.

> volatile, on the other hand, is inherently a characteristic of the
> access, not of the object.  Defining a volatile object does nothing in
> itself; it merely affects all accesses to the object.  Thus casting to
> volatile should mean that all uses of the resulting pointer should be
> done in a volatile fashion--i.e., all reads and writes done precisely
> as specified by the standard's "abstract machine."  Casting away from
> volatile means the reverse--there are no restrictions on the use of
> the object to which the pointer points.

Although I can see that this is how you might think about the
semantics of 'const' and 'volatile', I don't think they're an exact
match for the model in the standard.  In fact, I think you could
exchange the words 'const' and 'volatile' in the above and they would
be equally accurate.

The above reminds me of the arguments in physics about the wave or
particle nature of things.  The answer, of course, is that although
those are useful models, neither is an exact description of all the
properties.

Re: volatile semantics

[Paul Schlie]

> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> Paul Schlie <schlie@comcast.net> writes:
> 
> | > Gabriel Dos Reis writes:
> | > If by analysis, you can determine ...
> | 
> | The problem with this type of logic is that it leads to arbitrary
> | inconsistent designation of an object's reference as a function of
> | the breadth of the "analysis", therefore seems clearly undesirable.
> 
> There an inconsistency only if there is one in the program.

Yes, I fully agree.

In which case it seems most consistent to treat the object as
most recently specified, as opposed to potentially otherwise.

(as it's the UNCERTAINTY of POTENTIALLY which makes it less desirable,
than the unambiguous CERTAINTY of it's current effective declaration;
where if there is an inconsistency, at least the resulting effect will
be unambiguous; thereby abiding by the philosophy that two wrongs don't
make a right.)

Re: volatile semantics

[Gabriel Dos Reis]

Paul Schlie <schlie@comcast.net> writes:

| > Gabriel Dos Reis writes:
| > If by analysis, you can determine ...
| 
| The problem with this type of logic is that it leads to arbitrary
| inconsistent designation of an object's reference as a function of
| the breadth of the "analysis", therefore seems clearly undesirable.

There an inconsistency only if there is one in the program.

-- Gaby

Re: volatile semantics

[Paul Schlie]

> Gabriel Dos Reis writes:
> If by analysis, you can determine ...

The problem with this type of logic is that it leads to arbitrary
inconsistent designation of an object's reference as a function of
the breadth of the "analysis", therefore seems clearly undesirable.

Resulting in only two possibilities:

A: Treat all object references as initially declared (which isn't
   technically possible as function parameter declarations make this
   impossible to begin with, and inherently inconsistent with lvalue
   cast semantics).

B: Treat all object references as declared within their current scope,
   where the effective object declarations hierarchy looks basically
   like: <allocation-decl> [<parameter-decl> | <cast-decl>], where the
   most current represents the effective declaration of the object.

Thereby (B) represents the only tenable choice (there is no in-between).

[Which seems to be real simple to understand and abide by, regardless of
whether or not the resulting reference may specify an undefined behavior;
as the job of the compiler is to abide by the specified program, not go
out of it's way attempting to identify undefined behaviors so that it may
interject it's equally undefined inconsistent behaviors without regard to
the factual behavior that it's target would otherwise yield naturally if
it just simply warned and left well enough alone, presuming the author
desired what was specified, not something otherwise.]

Re: volatile semantics

[Gabriel Dos Reis]

kaih@khms.westfalen.de (Kai Henningsen) writes:

| gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 17.07.05 in <m3ll46s81y.fsf@uniton.integrable-solutions.net>:
| 
| > Daniel Berlin <dberlin@dberlin.org> writes:
| >
| > | On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| > | > Daniel Berlin <dberlin@dberlin.org> writes:
| > | >
| > | > [...]
| > | >
| > | > | You make it sound like  the standard is crystal clear on this issue,
| > | > and | everyone who disagrees with your viewpoint are just slimeballs
| > | > trying to | get around the clear wording of the standard.
| > | >
| > | > I think you're profondly mistaken in your understanding of what I wrote.
| > |
| > | I read it another few times, and still looks the same to me.
| > |
| > | "The way I see it is that people who designed and wrote the standard
| > | offer their view and interpretation of of they wrote and some people
| > | are determined to offer a different interpretation so that they can
| > | claim they are well-founded to apply  their transformations."
| > |
| > |
| > | IE there are those whose opinion is right because "they wrote the
| >
| > see, here is where you added the transmutation.
| 
| Well, the more interesting part is the one after "and some". And I agree  
| that it certainly reads rather insulting and confrontational - in fact, I  
| can't see how else to interpret it.
| 
| Can't we keep the personal attacks out of these discussions?

There were but, but it looks like you wanted to inject some.
That is without me.

-- Gaby

Re: volatile semantics

[Kai Henningsen]

gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 17.07.05 in <m3ll46s81y.fsf@uniton.integrable-solutions.net>:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
> | On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
> | > Daniel Berlin <dberlin@dberlin.org> writes:
> | >
> | > [...]
> | >
> | > | You make it sound like  the standard is crystal clear on this issue,
> | > and | everyone who disagrees with your viewpoint are just slimeballs
> | > trying to | get around the clear wording of the standard.
> | >
> | > I think you're profondly mistaken in your understanding of what I wrote.
> |
> | I read it another few times, and still looks the same to me.
> |
> | "The way I see it is that people who designed and wrote the standard
> | offer their view and interpretation of of they wrote and some people
> | are determined to offer a different interpretation so that they can
> | claim they are well-founded to apply  their transformations."
> |
> |
> | IE there are those whose opinion is right because "they wrote the
>
> see, here is where you added the transmutation.

Well, the more interesting part is the one after "and some". And I agree  
that it certainly reads rather insulting and confrontational - in fact, I  
can't see how else to interpret it.

Can't we keep the personal attacks out of these discussions?

MfG Kai

Re: volatile semantics

[Gabriel Dos Reis]

Mike Stump <mrs@apple.com> writes:

| On Jul 17, 2005, at 4:48 AM, Gabriel Dos Reis wrote:
| > C++ has resisted, for two decades, the temptation of "improving" the
| > meaning of volatile :-) considering that it is C's baby.
| 
| Do you know what the semantics of:
| 
|      a;
| 
| are in C and C++?
| 
| :-(

As much as I hate it; the rule was not designed to "improve" over
C-semantics of volatile.  It is in the same exception-family I mentioned
in the previous message. 

-- Gaby

Re: volatile semantics

[Mike Stump]

On Jul 17, 2005, at 4:48 AM, Gabriel Dos Reis wrote:
> C++ has resisted, for two decades, the temptation of "improving" the
> meaning of volatile :-) considering that it is C's baby.

Do you know what the semantics of:

     a;

are in C and C++?

:-(

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Paul Schlie <schlie@comcast.net>

| > |      void foo(void) {
| > |        int *x = 4;
| > |         *x = 3;

| The point I was attempting to make, was that just because a specified
| statement's effective behavior/side-effects are not well defined, it doesn't
| mean that it's clearly specified semantic actions may be summarily ignored.

The Standard specifically allows an implementation a lot of choices
when dealing with "undefined behavior".  Quoting n1124.pdf:

    3.4.3

    undefined behavior

    behavior, upon use of a nonportable or erroneous program construct
    or of erroneous for which this International Standard imposes no
    requirements

    NOTE Possible undefined behavior ranges from ignoring the
    situation completely with unpredictable results, to behaving
    during translation or program execution in a documented manner
    characteristic environment (with or without the issuance of a
    diagnostic message), to terminating a translation execution (with
    the issuance of a diagnostic message).

    EXAMPLE An example of undefined behavior is the behavior on
    integer overflow.

I think (but am not 100% sure) that this example falls into the
category of "undefined behavior".  Certainly the earlier example does.

So the implementation is free to do pretty much anything at all to the
program as a whole (for example, refuse to compile it) just because a
part of it invokes "undefined behavior".  Even though the NOTE does
not call this out, the implementation may do completely unreasonable
things -- the committee felt that it could not actually require
anything of an implementation when dealing with "undefined behavior".
Hence the wording "imposes no requirements" (but note that the sense
of that phrase in context is subtle).  The effect is no way prevented
from changing the behaviour of things that are well defined (the
undefinedness bleeds through to the whole program).

Not all Bad Things are categorized as "undefined behavior".

Let's think about your concrete example.  That assignment might (on a
reasonable implementation) curdle an interrupt vector.  Which might
have almost any effect on the execution of the program.  Including
apparently retroactive effects.  Certainly effects that cannot be
explained in the abstraction that is the C Standard +
implementation-supplied documentation mandated by the Standard.  No
wonder that the Standard throws up its hands.

[Sorry to be so long winded.  I think that being more concise would
enable more misunderstanding.]

Re: volatile semantics

[Paul Schlie]

> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> | - Just as if given:
> | 
> |      void foo(void) {
> |        int *x = 4;
> |         *x = 3;

The point I was attempting to make, was that just because a specified
statement's effective behavior/side-effects are not well defined, it doesn't
mean that it's clearly specified semantic actions may be summarily ignored.

Re: volatile semantics

[Gerald Pfeifer]

On Sun, 17 Jul 2005, D. Hugh Redelmeier wrote:
> If GCC4 causes this much problem with X, I wonder what GCC4 will do to
> the Linux kernel.

Current combinations of the Linux kernel and GCC 4.0 seem to work just 
fine, as far as I can tell.

Gerald

Re: volatile semantics

[Paul Schlie]

> From: Jonathan Wakely <cow@compsoc.man.ac.uk>
> On Sun, Jul 17, 2005 at 09:29:11PM -0400, Paul Schlie wrote:
> 
>>> Note that I'm explicitly not taking a position on what the standard says.
>>> The standard is notoriously incomplete with respect to object model issues,
>>> including volatility, so I think that trying particularly hard to parse its
>>> words in this area is probably not a good use of time for people trying to
>>> build a real-world compiler. Creating DRs is more useful than trying to read
>>> the tea leaves.
>>> 
>>> Clearly, the analogous rule does not make sense for "const" in that a
>>> "const" object can never be modified; in particular, if the compiler can
>>> prove that "*x = 3" is an attempt to modify an object whose dynamic type is
>>> "const int", then it can replace that with a call to "kill (SIGSEGV)", if it
>>> likes; this is unquestionably undefined behavior.
>> 
>> With all due respect, unless there is an explicit reference in the standard
>> to contradict it's clearly stated requirement that an object's qualified
>> lvalue ("locator value") designates the object being referenced, all
>> interpretations to the contrary are at best presumptuous, regardless of
>> whether or not it's generalized behavior may be indeterminate.
> 
> Does the first sentence of the following text count?
> 
>   6.7.3  Type qualifiers
> 
>        [#5] 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.113)

- I don't contest that the side effect of such an assignment is undefined,
  but do contest that an implementation has a right to arbitrarily modify
  validly specified semantic actions (regardless of whether they are well
  defined or not).

[but won't belabor the issue any further, as it's been discussed to death]

Re: volatile semantics

[Gabriel Dos Reis]

Paul Schlie <schlie@comcast.net> writes:

| > From: Paul Schlie <schlie@comcast.net>
| >> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| >> I don't understand what you mean here.  Are you seriously suggesting
| >> that 
| >> 
| >>      int main(void) {
| >>         const int x = 4;
| >>         *(int*)&x = 3;
| >>      }
| >> 
| >> is well-defined?

[...]

| - Just as if given:
| 
|      void foo(void) {
|        int *x = 4;

?

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Paul Schlie <schlie@comcast.net> writes:


[...]

| > | With all due respect, unless there is an explicit reference in the standard
| > | to contradict it's clearly stated requirement that an object's qualified
| > | lvalue ("locator value") designates the object being referenced, all
| > | interpretations to the contrary are at best presumptuous, regardless of
| > | whether or not it's generalized behavior may be indeterminate.
| > | 
| > | (but regardless, at least things are successively approximating "correct")
| > 
| > I don't understand what you mean here.  Are you seriously suggesting
| > that 
| > 
| >      int main(void) {
| >         const int x = 4;
| >         *(int*)&x = 3;
| >      }
| > 
| > is well-defined?
| 
| Actually yes, I believe it's well defined that:


       [#5] 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.113)

-- Gaby

Re: volatile semantics

[Paul Schlie]

> From: Paul Schlie <schlie@comcast.net>
>> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
>> I don't understand what you mean here.  Are you seriously suggesting
>> that 
>> 
>>      int main(void) {
>>         const int x = 4;
>>         *(int*)&x = 3;
>>      }
>> 
>> is well-defined?
> 
> Actually yes, I believe it's well defined that:
> 
> - The assignment reference to x is valid as it's not specified as const,
>   therefore must be performed, unless:
> 
> - It is KNOWN at the time of compilation that an absents of it's side effect
>   would have no logical consequential effect (as might be the case for
>   example if a write to a ROM allocated object were silently physically
>   ignored, but not for example if a write were specified to a RAM allocated
>   object), however:
> 
> - As allocation side effects may differ for different targets and/or
>   implementations, the behavioral consequence of the correctly specified and
>   valid assignment to a const declared object may also correspondingly
>   differ; so therefore although valid, the effect of the assignment is not
>   itself warranted to be portable (but that it will logically occur is).

- Just as if given:

     void foo(void) {
       int *x = 4;
       *x = 3;
       (const int *)x = 5;
     }

  The assignment to *x = 3 must logically occur (although it's not warranted
  what the behavioral effect of the assignment may actually be for a given
  target/implementation, as there's no requirement that RAM or anything in
  particular is mapped to address 4. (Unless an implementation KNOWS it's
  side effect is inconsequential to the execution of the specified program.)

  Correspondingly, (const int *)x = 5 must not logically occur, as an
  assignment to a const qualified object is invalid.

Re: volatile semantics

[Paolo Bonzini]

> - The assignment reference to x is valid as it's not specified as const,
>   therefore must be performed, unless:

You simply got the purpose of optimization and, to some extent, 
high-level languages wrong.  This thread shows that if people are 
reasonable (on both sides) a solution will be found.

Go back programming in assembly language.

Paolo

Re: volatile semantics

[Jonathan Wakely]

On Sun, Jul 17, 2005 at 09:29:11PM -0400, Paul Schlie wrote:

> > Note that I'm explicitly not taking a position on what the standard says.
> > The standard is notoriously incomplete with respect to object model issues,
> > including volatility, so I think that trying particularly hard to parse its
> > words in this area is probably not a good use of time for people trying to
> > build a real-world compiler. Creating DRs is more useful than trying to read
> > the tea leaves.
> >
> > Clearly, the analogous rule does not make sense for "const" in that a "const"
> > object can never be modified; in particular, if the compiler can prove that
> > "*x = 3" is an attempt to modify an object whose dynamic type is "const int",
> > then it can replace that with a call to "kill (SIGSEGV)", if it likes; this
> > is unquestionably undefined behavior.
> 
> With all due respect, unless there is an explicit reference in the standard
> to contradict it's clearly stated requirement that an object's qualified
> lvalue ("locator value") designates the object being referenced, all
> interpretations to the contrary are at best presumptuous, regardless of
> whether or not it's generalized behavior may be indeterminate.

Does the first sentence of the following text count?

  6.7.3  Type qualifiers

       [#5] 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.113)

jon

Re: volatile semantics

[Paul Schlie]

> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> | Paul Schlie <schlie@comcast.net> writes:
> | > Note that I'm explicitly not taking a position on what the standard says.
> | > The standard is notoriously incomplete with respect to object model
> | > issues, including volatility, so I think that trying particularly hard to
> | > parse its words in this area is probably not a good use of time for people
> | > trying to build a real-world compiler. Creating DRs is more useful than
> | > trying to read the tea leaves.
> | >
> | > Clearly, the analogous rule does not make sense for "const" in that a
> | > "const" object can never be modified; in particular, if the compiler can
> | > prove that "*x = 3" is an attempt to modify an object whose dynamic type
> | > is "const int", then it can replace that with a call to "kill (SIGSEGV)",
> | > if it likes; this is unquestionably undefined behavior.
> | 
> | With all due respect, unless there is an explicit reference in the standard
> | to contradict it's clearly stated requirement that an object's qualified
> | lvalue ("locator value") designates the object being referenced, all
> | interpretations to the contrary are at best presumptuous, regardless of
> | whether or not it's generalized behavior may be indeterminate.
> | 
> | (but regardless, at least things are successively approximating "correct")
> 
> I don't understand what you mean here.  Are you seriously suggesting
> that 
> 
>      int main(void) {
>         const int x = 4;
>         *(int*)&x = 3;
>      }
> 
> is well-defined?

Actually yes, I believe it's well defined that:

- The assignment reference to x is valid as it's not specified as const,
  therefore must be performed, unless:

- It is KNOWN at the time of compilation that an absents of it's side effect
  would have no logical consequential effect (as might be the case for
  example if a write to a ROM allocated object were silently physically
  ignored, but not for example if a write were specified to a RAM allocated
  object), however:

- As allocation side effects may differ for different targets and/or
  implementations, the behavioral consequence of the correctly specified and
  valid assignment to a const declared object may also correspondingly
  differ; so therefore although valid, the effect of the assignment is not
  itself warranted to be portable (but that it will logically occur is).

Re: volatile semantics

[Gabriel Dos Reis]

Paul Schlie <schlie@comcast.net> writes:

| > Note that I'm explicitly not taking a position on what the standard says.
| > The standard is notoriously incomplete with respect to object model issues,
| > including volatility, so I think that trying particularly hard to parse its
| > words in this area is probably not a good use of time for people trying to
| > build a real-world compiler. Creating DRs is more useful than trying to read
| > the tea leaves.
| >
| > Clearly, the analogous rule does not make sense for "const" in that a "const"
| > object can never be modified; in particular, if the compiler can prove that
| > "*x = 3" is an attempt to modify an object whose dynamic type is "const int",
| > then it can replace that with a call to "kill (SIGSEGV)", if it likes; this
| > is unquestionably undefined behavior.
| 
| With all due respect, unless there is an explicit reference in the standard
| to contradict it's clearly stated requirement that an object's qualified
| lvalue ("locator value") designates the object being referenced, all
| interpretations to the contrary are at best presumptuous, regardless of
| whether or not it's generalized behavior may be indeterminate.
| 
| (but regardless, at least things are successively approximating "correct")

I don't understand what you mean here.  Are you seriously suggesting
that 

     int main(void) {
        const int x = 4;
        *(int*)&x = 3;
     }

is well-defined?

-- Gaby

Re: volatile semantics

[Paul Schlie]

> Note that I'm explicitly not taking a position on what the standard says.
> The standard is notoriously incomplete with respect to object model issues,
> including volatility, so I think that trying particularly hard to parse its
> words in this area is probably not a good use of time for people trying to
> build a real-world compiler. Creating DRs is more useful than trying to read
> the tea leaves.
>
> Clearly, the analogous rule does not make sense for "const" in that a "const"
> object can never be modified; in particular, if the compiler can prove that
> "*x = 3" is an attempt to modify an object whose dynamic type is "const int",
> then it can replace that with a call to "kill (SIGSEGV)", if it likes; this
> is unquestionably undefined behavior.

With all due respect, unless there is an explicit reference in the standard
to contradict it's clearly stated requirement that an object's qualified
lvalue ("locator value") designates the object being referenced, all
interpretations to the contrary are at best presumptuous, regardless of
whether or not it's generalized behavior may be indeterminate.

(but regardless, at least things are successively approximating "correct")

Re: volatile semantics

[Mark Mitchell]

Daniel Berlin wrote:
> On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
> 
>>Daniel Berlin <dberlin@dberlin.org> writes:
>>
>>[...]
>>
>>| > I think that is urgent. 
>>| No offense, but everyone thinks the problems that affect them are the
>>| most urgent.
>>
>>miscompilation of KDE was declared urgent; I hope bug affecting code
>>semantics for X is not just "request for enhancement".
> 
> 
> Not for me to judge. That's why we have Mark.

For the record, I agree with what looks to have been the outcome of this 
thread: that it makes sense to consider an object volatile iff the type 
used to aspect the object is in fact volatile, regardless of its 
underlying type.  Certainly, the standard never requires that we remove 
accesses, and I do think that this rule is what programmers who use 
volatile expect, and it's an easy rule to explain, so, from a QoI point 
of view I think this is a good rule, independently of what behavior 
might be required by the standard.

Note that I'm explicitly not taking a position on what the standard 
says.  The standard is notoriously incomplete with respect to object 
model issues, including volatility, so I think that trying particularly 
hard to parse its words in this area is probably not a good use of time 
for people trying to build a real-world compiler.  Creating DRs is more 
useful than trying to read the tea leaves.

Clearly, the analogous rule does not make sense for "const" in that a 
"const" object can never be modified; in particular, if the compiler can 
prove that "*x = 3" is an attempt to modify an object whose dynamic type 
is "const int", then it can replace that with a call to "kill 
(SIGSEGV)", if it likes; this is unquestionably undefined behavior.

As for putting RTH's change in 4.0.2, I'm comfortable with that, 
provided the usual testing is done, as I think this is at least a QoI 
regression.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: volatile semantics

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| On Sun, Jul 17, 2005 at 05:03:55PM +0100, Nathan Sidwell wrote:
| > Issue 1.
| > void Foo (char *ptr) {
| >   *(volatile char *)ptr;
| > }
| ...
| > char c;
| > *(volatile char *)&c; // can this read be deleted?
| ...
| > void Foo (volatile char *ptr) {
| >   *(char *)ptr;
| 
| I did see Ian's summary,
| 
|   http://gcc.gnu.org/ml/gcc/2005-07/msg00714.html
| 
| wherein he ascribed the semantics of the volatile qualifier to the
| access, and not to the object.  I agree with his description completely,
| as I believe it embodies the intuition that C programmers have used
| wrt these qualifiers since forever.

Great!

even you explained yourself in a previous message, I think it would
have saved lots if you spoke earlier ;-p

| So the answers to the "deleteable" questions above are no, no, yes.
| 
| And it's probably a one-line bug in our "can this cast be removed"
| function.

Daniel Berlin posted an almost one-liner patch.

-- Gaby

Re: volatile semantics

[Richard Henderson]

On Sun, Jul 17, 2005 at 09:18:01AM -0700, Ian Lance Taylor wrote:
> This is PR 22278.  DannyB posted a simple, untested, patch here:
>     http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html

Thanks.  I think Danny's patch attacks this too late.  The 
following patch appears to do the right thing with the three
test cases I was given in another reply.

I'll bootstrap it right quick, and see if it has other odd
interactions with other test cases.

My time is limited today.  Anyone want to figure out the right
things to regexp on to make a set of testsuite entries for this?  
If not, I'll work on that Monday.


r~


	* gimplify.c (gimplify_expr): Create a non-volatile local to
	receive the result of a bare volatile read.
	* tree-ssa.c (tree_ssa_useless_type_conversion_1): Don't discard
	casts between pointers to volatile qualified types.

Index: gimplify.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.140
diff -u -p -d -r2.140 gimplify.c
--- gimplify.c	8 Jul 2005 23:36:40 -0000	2.140
+++ gimplify.c	17 Jul 2005 16:34:47 -0000
@@ -4411,8 +4411,9 @@ gimplify_expr (tree *expr_p, tree *pre_p
 	{
 	  /* Historically, the compiler has treated a bare
 	     reference to a volatile lvalue as forcing a load.  */
-	  tree tmp = create_tmp_var (TREE_TYPE (*expr_p), "vol");
-	  *expr_p = build (MODIFY_EXPR, TREE_TYPE (tmp), tmp, *expr_p);
+	  tree type = TYPE_MAIN_VARIANT (TREE_TYPE (*expr_p));
+	  tree tmp = create_tmp_var (type, "vol");
+	  *expr_p = build (MODIFY_EXPR, type, tmp, *expr_p);
 	}
       else
 	/* We can't do anything useful with a volatile reference to
Index: tree-ssa.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa.c,v
retrieving revision 2.105
diff -u -p -d -r2.105 tree-ssa.c
--- tree-ssa.c	13 Jul 2005 22:35:27 -0000	2.105
+++ tree-ssa.c	17 Jul 2005 16:34:47 -0000
@@ -890,6 +890,15 @@ tree_ssa_useless_type_conversion_1 (tree
   if (lang_hooks.types_compatible_p (inner_type, outer_type))
     return true;
 
+  /* Don't lose casts between pointers to volatile and non-volatile
+     qualified types.  Doing so would result in changing the semantics
+     of later accesses.  */
+  else if (POINTER_TYPE_P (inner_type)
+           && POINTER_TYPE_P (outer_type)
+	   && TYPE_VOLATILE (TREE_TYPE (outer_type))
+	      != TYPE_VOLATILE (TREE_TYPE (inner_type)))
+    return false;
+
   /* If both types are pointers and the outer type is a (void *), then
      the conversion is not necessary.  The opposite is not true since
      that conversion would result in a loss of information if the

Re: volatile semantics

[Ian Lance Taylor]

Richard Henderson <rth@redhat.com> writes:

> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?

As I read the messages, quite aside from the language lawyer issues, I
don't think anybody objects to the proposal that using a cast to
volatile should require gcc to do memory accesses as though the
original object were declared to be volatile.  (But this change should
not necessarily affect other type qualifiers).

Here is the test case.  The proposal is that the two functions should
be compiled to be essentially identical.  Currently gcc discards the
memory access in the first function: the 'int *' type of the object
wins over the 'volatile int *' type of the cast.

I happen to have gcc 2.96 (from Red Hat 7.3) and gcc 3.2 installed.
They both act as desired, and do not optimize out the read access.
mainline gcc does optimize out the read access in the first function,
foo.

void
foo (int *p)
{
  int i;

  i = *(volatile int *) p;
}

void
bar (volatile int *p)
{
  int i;

  i = *(volatile int *) p;
}

This is PR 22278.  DannyB posted a simple, untested, patch here:
    http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html

Ian

Re: volatile semantics

[Richard Henderson]

On Sun, Jul 17, 2005 at 05:03:55PM +0100, Nathan Sidwell wrote:
> Issue 1.
> void Foo (char *ptr) {
>   *(volatile char *)ptr;
> }
...
> char c;
> *(volatile char *)&c; // can this read be deleted?
...
> void Foo (volatile char *ptr) {
>   *(char *)ptr;

I did see Ian's summary,

  http://gcc.gnu.org/ml/gcc/2005-07/msg00714.html

wherein he ascribed the semantics of the volatile qualifier to the
access, and not to the object.  I agree with his description completely,
as I believe it embodies the intuition that C programmers have used
wrt these qualifiers since forever.

So the answers to the "deleteable" questions above are no, no, yes.

And it's probably a one-line bug in our "can this cast be removed"
function.


r~

Re: volatile semantics

[Falk Hueffner]

Richard Henderson <rth@redhat.com> writes:

> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?

Case 1:

void f1 (int *addr) {
    *((volatile int *) addr);
}

Case 2:

int c;
void f2 (int *addr) {
    *(volatile int *) &c;
}

gcc 4.0 omits read accesses for both, earlier ones didn't.

Opinions on what the standard prescribes here are divided. Opinions on
what the Right Thing[tm] to do seems to mostly agree on not omitting
the access in either case; however, there have been concerns on
whether we can reliably implement that.

-- 
	Falk

Re: volatile semantics

[Nathan Sidwell]

Richard Henderson wrote:
> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
yeah, I can understand that :)

> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?

Issue 1.
void Foo (char *ptr) {
  *(volatile char *)ptr;
}

can the read be deleted?  GCC 4 deletes it.

IMHO, no it cannot be deleted (when we do not know what object PTR points to).

Issue 2
can we delete the read, when we do determine that PTR points to a non-volatile
object.  I.e.

char c;
*(volatile char *)&c; // can this read be deleted?

IMHO, the standard is unclear.  It seems to me that deleting the read is not
disallowed.

Issue 3
void Foo (volatile char *ptr) {
  *(char *)ptr;
}

Again, is this read deleteable?  IMHO, yes.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Richard Henderson]

I've got no interest in reading a thread with 250 messages wherein
language lawyers battle it out in a no-holds-barred grudge match.
Would someone like to summarize, preferably with a test case that
one side assumes to be miscompiled?

Speaking with the optimizer hat on, we *don't* do much optimization
with volatile.  So if there's an access getting lost, it's probably
just a bug, and not cause for such consternation.


r~

Re: volatile semantics

[Michael Veksler]

Daniel Berlin <dberlin@dberlin.org> wrote on 17/07/2005 17:33:17:
> On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
[...]
> > I can't agree with that as is. I would refine it to:
> >   Anything that *does* optimizes away visible reads or writes of
> >   something marked volatile is buggy.
>
> Fine.
> But the tree optimizers currently make no distinction between reads and
> writes of volatile operands, or even which operands of a statement are
> volatile and which are not.  So from the perspective of what we do
> *now*, what i said is completely correct, because the optimizers do not
> (not "can not") distinguish to the level you want.
>
> I'd also guess it's probably not worth doing so, but i may be wrong.
>
Could be so, as volatile is not very commonly used (in regular
code). As for embedded code, I am not so sure, it could well be
that volatile is prevalent in embedded or in low level
code, making it a high impact issue in a big niche - I don't know.

Yet, marking the PRs as INVALID is probably not the correct
thing to do. Maybe WONTFIX, or something like that would be
more appropriate. As I understand GCC's bugzilla, INVALID means
that the report is incorrect. I think that the report finds a
true deficiency in gcc, and hence it is correct (a missed
optimization).

As for the importance of the missed optimization, nobody
can tell unless numbers are provided. So it would be fine to
postpone this PR indefinitely - until patches/numbers are
provided to persuade otherwise.

  Michael

Re: volatile semantics

[Daniel Berlin]

On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
> 
> 
> 
> Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
> 
> > Daniel Berlin <dberlin@dberlin.org> writes:
> >
> > | Anything it sees anything in a statement with volatile, it marks the
> > | statement as volatile, which should stop things from touching it
> > | (anything that *does* optimize something marked volatile is buggy).
> > great!
> >
> 
> I can't agree with that as is. I would refine it to:
>   Anything that *does* optimizes away visible reads or writes of
>   something marked volatile is buggy.

Fine.
But the tree optimizers currently make no distinction between reads and
writes of volatile operands, or even which operands of a statement are
volatile and which are not.  So from the perspective of what we do
*now*, what i said is completely correct, because the optimizers do not
(not "can not") distinguish to the level you want.

I'd also guess it's probably not worth doing so, but i may be wrong.

Re: volatile semantics

[Joseph S. Myers]

On Sun, 17 Jul 2005, Gabriel Dos Reis wrote:

> "D. Hugh Redelmeier" <hugh@mimosa.com> writes:
> 
> | | From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> | 
> | |  After many exchanges via private mails and
> | | looking at the various reports related to this issue, it has become
> | | clear to me that the interpretations offered to justify why GCC is
> | | behaving the way it does seem to go beyond what can be inferred.
> | 
> | OK.
> | 
> | Is there a consensus on this?
> 
> JSM, please chime in.

I'm not entering further into this mess.  I've already stated that the 
documentation should be clarified to make clear which of (effective type, 
declared type, type of lvalue used for access) is being used in GCC's 
definition of access to volatile objects and the code should be changed if 
the decision is to use the type of the lvalue used for the access (which 
would be a simple and natural rule to define).

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: volatile semantics

[Gabriel Dos Reis]

Andrew Haley <aph@redhat.com> writes:

[...]

| You know, the more this goes on the more I believe we should send
| X3J11 a request for clarification.  Perhaps X3J11 has been disbanded,
| so there may be problems.  But we should ask.

I don't know whether X3J11 is disbanded.  However, at the last meeting
in Norway, the liaison (John Benito) between ISO WG14 (C) and ISO WG21
(C++) reported, if I understood him correctly, that WG14 is not
considering "evolving" the C standard anymore, but I don't think they
ruled out DRs.  In the conversion with JSM, (when I suggested him a DR
report) he said that he sees no chance of WG14 wishing to refine
"volatile". 

The more this goes, the more it appears to me that the chain of
arguments to justify current GCC behaviour goes beyond what can be
inferred.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

[...]

| | At this point we need:
| |   (1) agreement from C and C++ maintainers on access through volatile
| |       lvalue 
| 
| I don't know C++ well enough to say whether the analogous optimization
| is wrong for C++.

C++ has resisted, for two decades, the temptation of "improving" the
meaning of volatile :-) considering that it is C's baby.

[ the only area where there is a difference betwenn C and C++ is
  things like  x = y = z; but that wasn't desined specifically to 
  "improve" over C's semantics of volatile. ]

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Andrew Pinski <pinskia@physics.uc.edu> writes:

| On Jul 16, 2005, at 11:07 PM, Gabriel Dos Reis wrote:
| 
| > | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
| >
| >    Andrew Pinski has declared this to be a bug, but the audit trail
| >    isn't clear as to why.
| 
| Because the abs is a function call, there is only one load and should
| be only
| one load as you pass the value to it.
| If you don't consider it a bug then I have no idea then I quit.

Please quit if you cannot understand take the statement as I wrote it:
I did not not say it was a bug or not a bug.

-- Gaby

Re: volatile semantics

[Andrew Haley]

Gabriel Dos Reis writes:
 > Daniel Berlin <dberlin@dberlin.org> writes:
 > 
 > | > | There is no point in type qualifiers if they can be simply changed at
 > | > | will.  Do not lie about your objects, and you will not be screwed over.
 > | > 
 > | > only if the language you're implementing the compiler for says so, no
 > | > matter what nifty transformation you could have done.
 > | > 
 > | 
 > | Except that nobody seems to agree that is what the language actually
 > | says.
 > 
 > The way I see it is that people who designed and wrote the standard
 > offer their view and interpretation of of they wrote and some people
 > are determined to offer a different interpretation so that they can
 > claim they are well-founded to apply  their transformations.

If "people who designed and wrote the standard" meant to say
something, perhaps they should have said so explicitly.  But that's
very hard to do with volatile, since its definition necessarily falls
outside the "as if" semantics of the language.

You know, the more this goes on the more I believe we should send
X3J11 a request for clarification.  Perhaps X3J11 has been disbanded,
so there may be problems.  But we should ask.

Andrew.

Re: volatile semantics

[Ian Lance Taylor]

Daniel Berlin <dberlin@dberlin.org> writes:

> > In other words, we're asked to agree that the type of an object
> > changes depending on how it is accessed.
> > For the benefit of readers, only the first sentence of this para is
> > the language of the standard; the rest isn't.  
> > 
> > That an object referred to through a volatile pointer must
> > "temporarily" be treated as though it were declared volatile is the
> > crux of this argument. 
> 
> Again, you could say the same about const, restrict, or any other
> qualifier then, making them more or less useless as qualifiers.

I think there may be a difference.

const is inherently a characteristic of the object.  It applies at
definition time.  Casting away const in a reference does not change
the definition.  Whether making an assignment through a pointer after
casting away const is legal depends upon how the definition of the
object pointed to is handled (C99 6.7.3: "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").

restrict is less interesting, since it simply provides a guarantee
about a pointer.  Casting away restrict does nothing useful--it just
abandons the guarantee.  Casting to restrict is by definition only
valid if the guarantee holds--if the object is indeed restricted (C99
6.7.3.1: ".... If these requirements are not met, then the behavior is
undefined").

volatile, on the other hand, is inherently a characteristic of the
access, not of the object.  Defining a volatile object does nothing in
itself; it merely affects all accesses to the object.  Thus casting to
volatile should mean that all uses of the resulting pointer should be
done in a volatile fashion--i.e., all reads and writes done precisely
as specified by the standard's "abstract machine."  Casting away from
volatile means the reverse--there are no restrictions on the use of
the object to which the pointer points.

I am not aware of any other type qualifiers in C or C++.

Ian

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Daniel Berlin <dberlin@dberlin.org>

| On Sat, 2005-07-16 at 21:36 -0400, D. Hugh Redelmeier wrote:
| > | From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| > 
| > |  After many exchanges via private mails and
| > | looking at the various reports related to this issue, it has become
| > | clear to me that the interpretations offered to justify why GCC is
| > | behaving the way it does seem to go beyond what can be inferred.
| > 
| > OK.
| > 
| > Is there a consensus on this?  If not, how can a consensus be reached?
| > 
| I'll pass on this, since I've said my piece, and i don't care about
| volatile much.

I would very much like you to restate your objections with careful
reference to the C Standard.  I really want the correct analysis more
than I want my analysis.

|  However, if you come after const or restrict I'll bite
| back.

What exactly do you think const says that you can find useful for
optimization?  I don't think that it is helpful (except on actual
definitions).  But I haven't looked closely at this issue.

| Personally, I think a DR should be filed to clarify this, instead of all
| this argument and opinion. 

I would like you to explain where you think that the current standard
is ambiguous on this matter.  Without ambiguity or error, a DR is not
appropriate.

| > If so, how can we get a fix?
| Usually by asking nicely and pressuring people. 
| Or waiting long enough for someone to get around to it.
| Or paying someone to fix it :)

Those are good answers.

| > I think that is urgent. 
| No offense, but everyone thinks the problems that affect them are the
| most urgent.

Yeah.  I've given a few arguments for urgency.

| >  This bug is causing X to misbehave and the
| > current workarounds might be harmful.  Who knows what other
| > manifestations might be lurking?
| 
| Whoever is testing distributions compiled with mainline :)

Testing can show the presence of bugs but not their absence.  But you
knew that.

| > As I said, I'm not a GCC hacker.  Who is the likely maintainer to fix
| > this?
| Anyone can fix it, however, who can review the fix depends on what it
| touches.
| 
| >  Does he or she agree that this needs to be done? 
| > Urgently?
| 
| This is actually probably pretty unlikely.  There are few bugs most
| people consider urgent, and i'd venture this is not one of them.  It
| would probably be fixed by release time.
| 
| In that spirit, here is a patch against mainline that fixes your bug (a
| similar patch to the same function should work on 4.0)

Thanks!

| Someone else can go through the process of testing and getting this
| reviewed, i'm currently swamped (IE i have no plans to try to submit
| this to gcc-patches).

Re: volatile semantics

[Andrew Pinski]

On Jul 16, 2005, at 11:07 PM, Gabriel Dos Reis wrote:

> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
>
>    Andrew Pinski has declared this to be a bug, but the audit trail
>    isn't clear as to why.

Because the abs is a function call, there is only one load and should 
be only
one load as you pass the value to it.
If you don't consider it a bug then I have no idea then I quit.

-- Pinski

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| 
| "D. Hugh Redelmeier" <hugh@mimosa.com> writes:
| 
| | | From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| | 
| | |  After many exchanges via private mails and
| | | looking at the various reports related to this issue, it has become
| | | clear to me that the interpretations offered to justify why GCC is
| | | behaving the way it does seem to go beyond what can be inferred.
| | 
| | OK.
| | 
| | Is there a consensus on this?
| 
| JSM, please chime in.

Maybe Joseph isn't seeing these messages.  I've added him to the CC list.  For 
that reason, I have not trimmed my quotations of your message.

Who wants off the CC list?  No fair if you are not subscribed to the
gcc list :-)

I've just now subscribed, so you can drop me from the CC lists.

| | If not, how can a consensus be reached?
| 
| try to explain those who read the standard to you their interpretation
| does not match the intent and the letter?  Sorry :-)

If I understand what you are saying, I guess the step before is to
have them construct an argument, quoting the standard, that supports
the buggy behaviour (he who frames the question wins :-).

| More seriously, at this point Daniel Berlin has indicated that he gives
| "less of a crap about volatile and optimizing volatile than [he does]
| const, restrict, etc".  So that is, I hope, a path to a saner behaviour
| from the code transformation part of the compiler.
| 
| | If so, how can we get a fix?
| | 
| | I think that is urgent.  This bug is causing X to misbehave and the
| | current workarounds might be harmful.  Who knows what other
| | manifestations might be lurking?
| | 
| | As I said, I'm not a GCC hacker.  Who is the likely maintainer to fix
| | this?  Does he or she agree that this needs to be done?  Urgently?
| 
| Joseph S. Myers (jsm at polyomino.org.uk)

Ah, polyominoes.  That is one area where I will claim some expertise.  For 
about 25 years I had enumerated more polyominoes than anyone else.

| and Richard Henderson (rth
| at redhat.com)

I've also added Richard to the CC list.

| are the C front-end maintainers.  The following is
| from the last message I received from Joseph (on access through volatile
| lvalue expression): 
| 
|   # Using always the qualification of the lvalue is reasonable semantics to 
|   # specify (I don't know about to implement).  It's still a matter of making 
|   # a choice and documenting and implementing it.
| 
| The issue is compounded by the fact that the code transformation part
| (the "optimizer") is maintained by a different set of people and it takes
| coordination between both worlds to arrive to a useful semantics. 
| 
| At this point we need:
|   (1) agreement from C and C++ maintainers on access through volatile
|       lvalue 

I don't know C++ well enough to say whether the analogous optimization
is wrong for C++.

|   (2) agreement with the middle-end maintainers not to "optimize"
|       volatile lvalue expressions
|   (3) document the behaviour.
| 
| The most important for you and X is to have (2) done, i.e. Richard
| Henderson, Roger Sayle, Daniel Berlin and others.
| 
| -- Gaby

As far as (3) is concerned, I think that the combination of the gcc
info node on Volatiles is pretty clear, when read in the context of
Henry's reading of the C standard.

It would be a good idea for everyone to read that node.

To read that node, invoke info:
	$ info gcc
Then type:
	gVolatiles<enter>
to go to the node "6.2 When is a Volatile Object Accessed?"

Re: volatile semantics

[Michael Veksler]

gdr@integrable-solutions.net wrote on 17/07/2005 08:30:26:

> Michael Veksler <VEKSLER@il.ibm.com> writes:
>
> | Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
> |
> | > Daniel Berlin <dberlin@dberlin.org> writes:
> | >
> | > | Anything it sees anything in a statement with volatile, it marks
the
> | > | statement as volatile, which should stop things from touching it
> | > | (anything that *does* optimize something marked volatile is buggy).
> | > great!
> | >
> |
> | I can't agree with that as is. I would refine it to:
> |   Anything that *does* optimizes away visible reads or writes of
> |   something marked volatile is buggy.
>
> How do you define "visible reads or writes", and how is it different
> from Daniel's statement?

Visible reads or writes is to be defined by the hardware:
The most percise definition would include cache coherency
and other very complicated hardware isssues. For now I'll
only say that "visible reads or writes" follow the "as if"
rule from hardware's point of view(equivalent cache/bus
activity for external memory address, a bit more tricky
to define for internal memory addresses).

From Daniel's statement it follows that you are not
allowed to do what PR 3506 wants to do:

To generate:
        incl      y
Instead of:
        movl    y, %eax
        incl      %eax
        movl    %eax, y

Becuase "anything that *does* optimize something marked volatile
is buggy" [Daniel Berlin].

I say that it is perfectly legal to do so, provided that "incl y"
is not atomic.

My statements are correct as long as the following is allowed to
become an infinite loop:


1:f()
2:{
3:    static volatile int i=0;
4:    while (i <= 1 && i >=0)
5:    {
6:        ++i;
7:        --i;
8:    }
9:}

When f() is simultaneously called from 2 threads.

A possible run before the transformation:

time=0: i==0 ;  thread 0 [line 6]: reg=i ; ++reg ; next(i) == 0
time=1: i==0 ;  thread 1 [line 6]: reg=i ; ++reg ; next(i) == 0
time=2: i==0 ;  thread 1 [line 6]: i=reg ; next(i) == 1
time=3: i==0 ;  thread 0 [line 6]: i=reg ; next(i) == 1
time=4: i==1 ; thread 0 [line 7]: reg=i; ++reg; i=reg; next(i)==2
time=5: i==2 ; thread 0 [line 4]; i <= 1 --> is false: break loop


After the transformation, "inc i" will be an atomic operation
for a single processor. As a result, no two ++i will be able
to operate in parallel (on a single processor), and times [0..3]
will no longer be able to interleave. As a result, this will be
an infinite loop.

With MP or with a multi-threaded processor [inc i] will not be
atomic (correct me if I am wrong WRT x86), so the above
run is still possible - even after transformation.


Considering the above example, do you think that this
transformation is invalid?


  Michael

Re: volatile semantics

[Gabriel Dos Reis]

Michael Veksler <VEKSLER@il.ibm.com> writes:

| Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
| 
| > Daniel Berlin <dberlin@dberlin.org> writes:
| >
| > | Anything it sees anything in a statement with volatile, it marks the
| > | statement as volatile, which should stop things from touching it
| > | (anything that *does* optimize something marked volatile is buggy).
| > great!
| >
| 
| I can't agree with that as is. I would refine it to:
|   Anything that *does* optimizes away visible reads or writes of
|   something marked volatile is buggy.

How do you define "visible reads or writes", and how is it different
from Daniel's statement?

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

[...]

| If GCC4 causes this much problem with X, I wonder what GCC4 will do to
| the Linux kernel.  I understand that Linus generally prefers older
| GCCs to newer ones.  It would be great if his preference were only
| superstition.

I do not follow the linux kernel on a regular basis, so I may miss
things there.  However, I regularly follow the GMP development list
and it has been advised by GMP delopers NOT to use GCC4.0.x because of
alleged miscompilation problems 

   http://www.swox.com/gmp/

     [...]

     For GMP 4.1.4, we recommend that you use GCC 3.3.x or
     older. We've had some luck with GCC 3.4.x on some systems, but we
     have yet to find a system where GCC 4.0 builds, and neither
     crashes or miscompiles the GMP sources.

I have not analysed the problems in GMP and make no claim that it has
to do with volatile or not.  Torbjörn knows more:

   http://swox.com/list-archives/gmp-discuss/2005-July/001750.html

-- Gaby

Re: volatile semantics

[Michael Veksler]

Gabriel Dos Reis wrote on 17/07/2005 06:07:29:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
> | Anything it sees anything in a statement with volatile, it marks the
> | statement as volatile, which should stop things from touching it
> | (anything that *does* optimize something marked volatile is buggy).
> great!
>

I can't agree with that as is. I would refine it to:
  Anything that *does* optimizes away visible reads or writes of
  something marked volatile is buggy.

> | I should note that this will probably annoy the people who reported :
> |
> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
>
> The rationale is:
>
>    GCC doesn't know what constitutes a reference to a volatile memory,
>     so it never performs operations on them directly.  It will always
>     pull the value into a register first.

This can be optimized, without violating the rule for read/write
visibility. It was over a decade since I were on a Pentium validation
team, so I may be wrong:
  inc mem - without a LCK prefix is not atomic, generating a
  read, and then write - behaving as if it were 3 instructions:
  [read mem; inc; write mem].
What I am getting at, is that gcc is *allowed* to optimize any
sequence of the form [read mem; arithmetic; write mem] to
[arithmetic mem], even for a  volatile int.


I do *not* say that this *has* to be optimized, only that it could.
If it had to, gcc would have a very difficult time with RISC
load/store architectures. No reasonable interpretation of the
standard may claim that gcc *should* generate a single "inc y".
I claim that in this case gcc *could* generate a single "inc y",
and as such it is a missed optimization (and the PR is valid).

It may be a very difficult optimization to implement, so
it can be postponed indefinitely, but it should not be marked
INVALID. It should be marked a SUSPENDED missed
optimization opportunity (for x86 and probably several
other CISCs - as long as read/write is not atomic).


   Michael

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Gabriel Dos Reis <gdr@integrable-solutions.net>

| Daniel Berlin <dberlin@dberlin.org> writes:
| 
| [...]
| 
| | > I think that is urgent. 
| | No offense, but everyone thinks the problems that affect them are the
| | most urgent.
| 
| miscompilation of KDE was declared urgent; I hope bug affecting code
| semantics for X is not just "request for enhancement".

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242#c120
[Comment 120, if your browser doesn't get to the right spot]

Here is the text, written by Olivier Baudron:

    There are 100+ casts into volatile in xorg-x11 and some of them
    are in libvgahw.  All of these are "miscompiled" by gcc4 -O2. The
    patch in -43 (one volatile fixed in libvgahw) was enough for my
    G400.  Unfortunatly, other hardware are depending upon volatile
    side effects found elsewhere in libvgahw or even elsewhere in
    xorg. Thus reported scenarii a,b,c,d are easily understood.

    For now, we have fixed: 1 bug out of 100+ in 1 package out of
    1000+.  I *really* suggest gcc4 be compatible with gcc3 in a near
    future.

I have not verified these numbers, but they do make the bug seem
serious.


Just as I'm not a GCC hacker, I'm not an X hacker nor a kernel hacker.
What follows is idle speculation.

My feeling (i.e. it is not certain knowledge) is that a lot of X
driver code may represent scar tissue from battles with intransigent
hardware.  There may not be explicit specs that the code is following.
This may make migrating the code to another approach to volatile
somewhat destabilizing.

Another feeling I have is that 100+ casts to volatile are an
indication that the code should be refactored.  A long-term process
that should not be attempted in an emergency.

If GCC4 causes this much problem with X, I wonder what GCC4 will do to
the Linux kernel.  I understand that Linus generally prefers older
GCCs to newer ones.  It would be great if his preference were only
superstition.

Re: volatile semantics

[Michael Veksler]

Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
>
> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
>
>    Andrew Pinski has declared this to be a bug, but the audit trail
>    isn't clear as to why.
>

Maybe because gcc treats -O1 differently from -O2, -O3,
and -Os ? Also, since abs is a (built in) function, passing
  extern volatile int i1;
as a parameter to abs(int) should be generating a single
memory access - only when the parameter is created.
The implementation of abs should not matter in this case -
as the parameter has already been copied.

If abs was implemented as inline rather than built in:
  inline int abs(int a) { return a < 0 ? -a : a ; }
would it still generate 2 loads? This does not make sense,
since abs is a separate function, with `a' being declared as
a non-volatile variable.


  Michael

Re: volatile semantics

[Daniel Berlin]

On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> [...]
> 
> | > I think that is urgent. 
> | No offense, but everyone thinks the problems that affect them are the
> | most urgent.
> 
> miscompilation of KDE was declared urgent; I hope bug affecting code
> semantics for X is not just "request for enhancement".

Not for me to judge. That's why we have Mark.
As i said, it would probably be fixed before 4.1 whether done by me or
someone else.

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

[...]

| > I think that is urgent. 
| No offense, but everyone thinks the problems that affect them are the
| most urgent.

miscompilation of KDE was declared urgent; I hope bug affecting code
semantics for X is not just "request for enhancement".

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| Anything it sees anything in a statement with volatile, it marks the
| statement as volatile, which should stop things from touching it
| (anything that *does* optimize something marked volatile is buggy).

great!

| I should note that this will probably annoy the people who reported :
| 	
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506

The rationale is:

   GCC doesn't know what constitutes a reference to a volatile memory,
    so it never performs operations on them directly.  It will always
    pull the value into a register first.

| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18617

If the statement that anything that does optimze something marked
volatile is buggy, how can that PR be considered a bug in GCC?

| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21580

  GCC generates:

     (1) read the volatile variable into location rho;
     (2) compute rho <- rho + 1
     (3) store rho back in the variable

As far as I can see, this matches the previous statement that anything
that is marrked volatile is not optimized.  
    

| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222

   Andrew Pinski has declared this to be a bug, but the audit trail
   isn't clear as to why.

| (there's a couple others).
| 
| Then again, I'm pretty  willing at this point to laugh at people who use
| volatile and complain about code quality

then you'll be in good company ;-/

-- Gaby

Re: volatile semantics

[Daniel Berlin]

> At this point we need:
>   (1) agreement from C and C++ maintainers on access through volatile
>       lvalue 
>   (2) agreement with the middle-end maintainers not to "optimize"
>       volatile lvalue expressions

We already don't optimize expressions considered to have "volatile"
operands.

It's just our definition of volatile operands did not include this.
The patch i sent is probably overkill in this regard to this specific
semantic.

Anything it sees anything in a statement with volatile, it marks the
statement as volatile, which should stop things from touching it
(anything that *does* optimize something marked volatile is buggy).

I should note that this will probably annoy the people who reported :
	
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18617
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21580
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222

(there's a couple others).

Then again, I'm pretty  willing at this point to laugh at people who use
volatile and complain about code quality (even if most of those end up
being caused in the backend)

--Dan

Re: volatile semantics

[Daniel Berlin]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On Sat, 2005-07-16 at 21:36 -0400, D. Hugh Redelmeier wrote:
> | From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> 
> |  After many exchanges via private mails and
> | looking at the various reports related to this issue, it has become
> | clear to me that the interpretations offered to justify why GCC is
> | behaving the way it does seem to go beyond what can be inferred.
> 
> OK.
> 
> Is there a consensus on this?  If not, how can a consensus be reached?
> 
I'll pass on this, since I've said my piece, and i don't care about
volatile much.  However, if you come after const or restrict I'll bite
back.
Personally, I think a DR should be filed to clarify this, instead of all
this argument and opinion. 

> If so, how can we get a fix?
Usually by asking nicely and pressuring people. 
Or waiting long enough for someone to get around to it.
Or paying someone to fix it :)

> 
> I think that is urgent. 
No offense, but everyone thinks the problems that affect them are the
most urgent.

>  This bug is causing X to misbehave and the
> current workarounds might be harmful.  Who knows what other
> manifestations might be lurking?

Whoever is testing distributions compiled with mainline :)

> 
> As I said, I'm not a GCC hacker.  Who is the likely maintainer to fix
> this?
Anyone can fix it, however, who can review the fix depends on what it
touches.

>  Does he or she agree that this needs to be done? 
> Urgently?

This is actually probably pretty unlikely.  There are few bugs most
people consider urgent, and i'd venture this is not one of them.  It
would probably be fixed by release time.

In that spirit, here is a patch against mainline that fixes your bug (a
similar patch to the same function should work on 4.0)

Someone else can go through the process of testing and getting this
reviewed, i'm currently swamped (IE i have no plans to try to submit
this to gcc-patches).

Have a nice weekend,
Dan


[-- Attachment #2: volatilefix.diff --]
[-- Type: text/x-patch, Size: 560 bytes --]

Index: tree-ssa-operands.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-operands.c,v
retrieving revision 2.95
diff -u -p -r2.95 tree-ssa-operands.c
--- tree-ssa-operands.c	13 Jul 2005 15:34:16 -0000	2.95
+++ tree-ssa-operands.c	17 Jul 2005 02:26:21 -0000
@@ -1224,6 +1224,9 @@ get_expr_operands (tree stmt, tree *expr
   code = TREE_CODE (expr);
   class = TREE_CODE_CLASS (code);
 
+  if (TREE_THIS_VOLATILE (expr))
+    s_ann->has_volatile_ops = true;
+
   switch (code)
     {
     case ADDR_EXPR:

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

| | From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| 
| |  After many exchanges via private mails and
| | looking at the various reports related to this issue, it has become
| | clear to me that the interpretations offered to justify why GCC is
| | behaving the way it does seem to go beyond what can be inferred.
| 
| OK.
| 
| Is there a consensus on this?

JSM, please chime in.

| If not, how can a consensus be reached?

try to explain those who read the standard to you their interpretation
does not match the intent and the letter?  Sorry :-)

More seriously, at this point Daniel Berlin has indicated that he gives
"less of a crap about volatile and optimizing volatile than [he does]
const, restrict, etc".  So that is, I hope, a path to a saner behaviour
from the code transformation part of the compiler.

| If so, how can we get a fix?
| 
| I think that is urgent.  This bug is causing X to misbehave and the
| current workarounds might be harmful.  Who knows what other
| manifestations might be lurking?
| 
| As I said, I'm not a GCC hacker.  Who is the likely maintainer to fix
| this?  Does he or she agree that this needs to be done?  Urgently?

Joseph S. Myers (jsm at polyomino.org.uk) and Richard Henderson (rth
at redhat.com) are the C front-end maintainers.  The following is
from the last message I received from Joseph (on access through volatile
lvalue expression): 

  # Using always the qualification of the lvalue is reasonable semantics to 
  # specify (I don't know about to implement).  It's still a matter of making 
  # a choice and documenting and implementing it.

The issue is compounded by the fact that the code transformation part
(the "optimizer") is maintained by a different set of people and it takes
coordination between both worlds to arrive to a useful semantics. 

At this point we need:
  (1) agreement from C and C++ maintainers on access through volatile
      lvalue 
  (2) agreement with the middle-end maintainers not to "optimize"
      volatile lvalue expressions
  (3) document the behaviour.

The most important for you and X is to have (2) done, i.e. Richard
Henderson, Roger Sayle, Daniel Berlin and others.

-- Gaby

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Gabriel Dos Reis <gdr@integrable-solutions.net>

|  After many exchanges via private mails and
| looking at the various reports related to this issue, it has become
| clear to me that the interpretations offered to justify why GCC is
| behaving the way it does seem to go beyond what can be inferred.

OK.

Is there a consensus on this?  If not, how can a consensus be reached?

If so, how can we get a fix?

I think that is urgent.  This bug is causing X to misbehave and the
current workarounds might be harmful.  Who knows what other
manifestations might be lurking?

As I said, I'm not a GCC hacker.  Who is the likely maintainer to fix
this?  Does he or she agree that this needs to be done?  Urgently?

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

| | From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| 
| | The way I see it is that people who designed and wrote the standard
| | offer their view and interpretation of of they wrote and some people
| | are determined to offer a different interpretation so that they can
| | claim they are well-founded to apply  their transformations.
| 
| I don't know exactly what you are referring to here.  That's OK, I
| think.

yes :-)

| The standard should stand alone.  It should be able to be interpreted
| without "insider knowledge".

fully agreed.

| The standard is quite complicated and intricate.  It helps to already
| know it when trying to read it.  (On the other hand, that same
| phenomenon makes it hard for the authors to see its ambiguities.)

again agreed.

| Generations have worked on improving the standards.  Not all of the
| changes were made by people who understood what went before.

no displute there.

| Having said all that, I think that the standard gives no authority to
| do the optimization that GCC4 is doing to the code sample I gave.  I
| included Henry's carefully justified-by-scripture argument.  If anyone
| disagrees, PLEASE give a careful argument why, siting the Standard.
| 
| If you wish to answer other questions about the standard, I recommend
| that the first step would be to read the standard.  Arguing by opinion
| isn't getting us too far.

Again agreed.

| PS: thanks for not just ignoring my report.

well, feedbacks are always welcome and it would not help us if we did
"just ignore" them.  After many exchanges via private mails and
looking at the various reports related to this issue, it has become
clear to me that the interpretations offered to justify why GCC is
behaving the way it does seem to go beyond what can be inferred.

-- Gaby

Re: volatile semantics

[D. Hugh Redelmeier]

| From: Gabriel Dos Reis <gdr@integrable-solutions.net>

| The way I see it is that people who designed and wrote the standard
| offer their view and interpretation of of they wrote and some people
| are determined to offer a different interpretation so that they can
| claim they are well-founded to apply  their transformations.

I don't know exactly what you are referring to here.  That's OK, I
think.

The standard should stand alone.  It should be able to be interpreted
without "insider knowledge".

The standard is quite complicated and intricate.  It helps to already
know it when trying to read it.  (On the other hand, that same
phenomenon makes it hard for the authors to see its ambiguities.)

Generations have worked on improving the standards.  Not all of the
changes were made by people who understood what went before.

Having said all that, I think that the standard gives no authority to
do the optimization that GCC4 is doing to the code sample I gave.  I
included Henry's carefully justified-by-scripture argument.  If anyone
disagrees, PLEASE give a careful argument why, siting the Standard.

If you wish to answer other questions about the standard, I recommend
that the first step would be to read the standard.  Arguing by opinion
isn't getting us too far.

PS: thanks for not just ignoring my report.

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <dberlin@dberlin.org> writes:
| > 
| > [...]
| > 
| > | You make it sound like  the standard is crystal clear on this issue, and
| > | everyone who disagrees with your viewpoint are just slimeballs trying to
| > | get around the clear wording of the standard.
| > 
| > I think you're profondly mistaken in your understanding of what I wrote.
| 
| I read it another few times, and still looks the same to me.
| 
| "The way I see it is that people who designed and wrote the standard
| offer their view and interpretation of of they wrote and some people
| are determined to offer a different interpretation so that they can
| claim they are well-founded to apply  their transformations."
| 
| 
| IE there are those whose opinion is right because "they wrote the

see, here is where you added the transmutation.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| We both know that standards committees are not made up of 1 or 2 people,
| and saying "people who designed and wrote the standard offer their view
| and interpretation of of they wrote " is not useful when they do not
| actually speak for the committee.

Clearly, the communication channel to read you has a serious problem.

-- Gaby

Re: volatile semantics

[Daniel Berlin]

On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> [...]
> 
> | You make it sound like  the standard is crystal clear on this issue, and
> | everyone who disagrees with your viewpoint are just slimeballs trying to
> | get around the clear wording of the standard.
> 
> I think you're profondly mistaken in your understanding of what I wrote.

I read it another few times, and still looks the same to me.

"The way I see it is that people who designed and wrote the standard
offer their view and interpretation of of they wrote and some people
are determined to offer a different interpretation so that they can
claim they are well-founded to apply  their transformations."


IE there are those whose opinion is right because "they wrote the
standard" (even though they don't actually speak for the standards
committee as individuals), and everyone else is just trying to get
around what they say.

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

[...]

| You make it sound like  the standard is crystal clear on this issue, and
| everyone who disagrees with your viewpoint are just slimeballs trying to
| get around the clear wording of the standard.

I think you're profondly mistaken in your understanding of what I wrote.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <dberlin@dberlin.org> writes:
| > 
| > | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| > | > Daniel Berlin wrote:
| > | > >>> object volatile).
| > | > >>
| > You don't make people happier by transmutating their programs into
| > faster executable with (what they think) wrong semantics where there is no
| > way you can clearly and unambiguously justify those transformations.
| 
| Again, you try and posit it your view as clear and unambiguous when it
| simply isn't.
| It's not even close to that.
| 
| Personally, I actually give less of a crap about volatile and optimizing
| volatile than i do const, restrict, etc.  As long as you guys aren't
| going to start claiming this type of "Oh well, now my object is
| volatile, and now it's not, and now it is again, and now it's not.  Look
| at me, i'm dancing!" for other things, it's fine by me.

I generally don't care about volatile -- I don't believe it is a very
useful progroamming language device given its current definition.  I
care only when its implementation hurts users.

| Also, if we are going to play the "well, volatile is just different
| game", and you want no optimization whatsoever when someone says
| "volatile", then fine.

It is not me inventing that.  

|  I really have no problem with that.  I'll also
| simply point all the bug reports we get about "volatile not being
| optimized well" (sadly, we have them, take a gander :( ) to you or
| whoever wants to explain what semantic you think is correct.

Please give me references, it always is good thing.

-- Gaby

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
> | > Daniel Berlin wrote:
> | > >>> object volatile).
> | > >>
> You don't make people happier by transmutating their programs into
> faster executable with (what they think) wrong semantics where there is no
> way you can clearly and unambiguously justify those transformations.

Again, you try and posit it your view as clear and unambiguous when it
simply isn't.
It's not even close to that.

Personally, I actually give less of a crap about volatile and optimizing
volatile than i do const, restrict, etc.  As long as you guys aren't
going to start claiming this type of "Oh well, now my object is
volatile, and now it's not, and now it is again, and now it's not.  Look
at me, i'm dancing!" for other things, it's fine by me.

Also, if we are going to play the "well, volatile is just different
game", and you want no optimization whatsoever when someone says
"volatile", then fine.  I really have no problem with that.  I'll also
simply point all the bug reports we get about "volatile not being
optimized well" (sadly, we have them, take a gander :( ) to you or
whoever wants to explain what semantic you think is correct.

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> | > | There is no point in type qualifiers if they can be simply changed at
> | > | will.  Do not lie about your objects, and you will not be screwed over.
> | > 
> | > only if the language you're implementing the compiler for says so, no
> | > matter what nifty transformation you could have done.
> | > 
> | 
> | Except that nobody seems to agree that is what the language actually
> | says.
> 
> The way I see it is that people who designed and wrote the standard
> offer their view and interpretation of of they wrote and some people
> are determined to offer a different interpretation so that they can
> claim they are well-founded to apply  their transformations.

It's nice of you to characterize it in such divisive and confrontational
terms. 

You make it sound like  the standard is crystal clear on this issue, and
everyone who disagrees with your viewpoint are just slimeballs trying to
get around the clear wording of the standard.

And if you don't mean to sound like that, you sure need to be more
careful, because it sure sounds like that to me.

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> | > | There is no point in type qualifiers if they can be simply changed at
> | > | will.  Do not lie about your objects, and you will not be screwed over.
> | > 
> | > only if the language you're implementing the compiler for says so, no
> | > matter what nifty transformation you could have done.
> | > 
> | 
> | Except that nobody seems to agree that is what the language actually
> | says.
> 
> The way I see it is that people who designed and wrote the standard
> offer their view and interpretation of of they wrote and some people
> are determined to offer a different interpretation so that they can
> claim they are well-founded to apply  their transformations.

I'm sorry, i have a hard time believing the view of what amounts so far
to 2 people is that of the standard committee.
After all, if the standard is really that unclear, someone could file a
DR and we could get an official answer.

We both know that standards committees are not made up of 1 or 2 people,
and saying "people who designed and wrote the standard offer their view
and interpretation of of they wrote " is not useful when they do not
actually speak for the committee.

--Dan

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| > Daniel Berlin wrote:
| > >>> object volatile).
| > >>
| > >>
| > >> I don't understand your point. given
| > >>     void Foo (char const * a) { *(char *)a = 5; }
| > >> the compiler generates code to store 5 through the pointer 'a'.  It
| > >> doesn't turn
| > >> this into a call to 'abort', because it thinks you're writing to const
| > >> storage.
| > > 
| > > 
| > > Is this *always* the cast, or just in the example above?
| > 
| > I thought we were discussing the case where there is no static information about
| > what the pointer actually points to. I.e. the case of an incoming pointer
| > parameter of a function that is not being inlined (or equivalent).
| 
| If so, i  have no problem, but then you end up with people claiming we
| shouldn't know info we actually do, etc.

I find that fuzzy formulation of the issue rather quite disturbing.
Nobody is claiming you should not know what you know.  What people
claim is under which circumstances you can apply transformations based
on the information you know, i.e. when those transformations are valid.

You don't make people happier by transmutating their programs into
faster executable with (what they think) wrong semantics where there is no
way you can clearly and unambiguously justify those transformations.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| > | There is no point in type qualifiers if they can be simply changed at
| > | will.  Do not lie about your objects, and you will not be screwed over.
| > 
| > only if the language you're implementing the compiler for says so, no
| > matter what nifty transformation you could have done.
| > 
| 
| Except that nobody seems to agree that is what the language actually
| says.

The way I see it is that people who designed and wrote the standard
offer their view and interpretation of of they wrote and some people
are determined to offer a different interpretation so that they can
claim they are well-founded to apply  their transformations.

| BTW, telling us what C++ says is not really interesting, and only adds
| to confusion, since we are talking solely about C here

No.  The issue pops up in both languages and they share the same
transformation machinery, even if the bug was originally reported only
for C.  I would hate to have to go through this again with you, so I
rather make sure that you understand.  No confusion added.

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Dale Johannesen <dalej@apple.com> writes:

| >  the type of an object
| > changes depending on how it is accessed.
| 
| this also makes nonsense of gcc's implementation of type-based aliasing
| rules.
| 
|    *((int *)&x) = 3

No.  That one is specifically covered by the C and C++  standards
(although they use different terminologies).  C uses the notion of
*effective type* to formulate the rule.


       [#6] The effective type of an object for an  access  to  its
       stored value is the declared type of the object, if any.72)
       If a value is stored into an object having no declared  type
       through  an  lvalue  having  a  type that is not a character
       type, then the type of the lvalue becomes the effective type
       of  the  object  for that access and for subsequent accesses
       that do not modify the stored value.  If a value  is  copied
       into  an  object  having  no  declared  type using memcpy or
       memmove, or is copied as an array of  character  type,  then
       the  effective  type  of the modified object for that access
       and for subsequent accesses that do not modify the value  is
       the  effective  type  of  the object from which the value is
       copied, if it has one.  For all other accesses to an  object
       having no declared type, the effective type of the object is
       simply the type of the lvalue used for the access.


-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

[...]

| - let's not talk about "restrict"

Oh, it was getting fun :-)

-- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| >> object volatile).
| >
| > I don't understand your point. given
| > 	void Foo (char const * a) { *(char *)a = 5; }
| > the compiler generates code to store 5 through the pointer 'a'.  It doesn't turn
| > this into a call to 'abort', because it thinks you're writing to const storage.
| 
| Is this *always* the cast, or just in the example above?
| 
| >
| > So, here it appears the compiler does believe the (char *) cast.
| 
| I imagine this is due to some workaround in an optimizer for some bug
| it exposed elswhere.

I do not understand your sentence; could you clarify?

Given the above definition of Foo(), the following shall pass
assertion

        int main()
        {
               int char a = 30;
               Foo(&a);
               assert(a == 5); 
        }


| >  Why should it
| > not believe a (char volatile *) cast -- unless it can determine the static type
| > of the object pointed to?
| 
| It appears he was saying that *even if it could determine the static
| type*, the volatile qualifier on the cast *made the object not that
| type anymore*.


I think care needs to be exercise here about terminology, because it
appears that everybody has its own dialect that ultimately leads to
lot of confusion.  Let me give my answer based on the terminology 
in the C++ standard that I'll reprroduce below.

If you can determine that the *dynamic type* of an object is const,
and yet users writes to it, then you're well-founded to do whatever
you like.  Whoever, just using the static type without further
information that relates it to the dynamic type is insufficient.

Similarly, if you can determine that the dynamic type of an object is
volatile, yet uses access it through non volatile then you can
whatever you like with the program.

Notice that "dynamic type" talks about type of objects, whereas static
type talks about type of expression.
   

   1.3.3 dynamic type 
   the type of the most derived object (1.8) to which the lvalue
   denoted by an lvalue expression refers. [Example: if a pointer
   (8.3.1) p whose static type is pointer to class B is pointing to an
   object of class D, derived from B (clause 10), the dynamic type of
   the expression *p is D. References (8.3.2) are treated similarly. ] 
   The dynamic type of an rvalue expression is its static type.

   1.3.11 static type
   the type of an expression (3.9), which type results from analysis
   of the program without considering execution semantics. The static
   type of an expression depends only on the form of the program in
   which the expression appears, and does not change while the program
   is executing. 

Re: volatile semantics

[Daniel Berlin]

> | There is no point in type qualifiers if they can be simply changed at
> | will.  Do not lie about your objects, and you will not be screwed over.
> 
> only if the language you're implementing the compiler for says so, no
> matter what nifty transformation you could have done.
> 

Except that nobody seems to agree that is what the language actually
says.

BTW, telling us what C++ says is not really interesting, and only adds
to confusion, since we are talking solely about C here

> -- Gaby

Re: volatile semantics

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
| > Sorry for the very late response.  It is actually triggered by the
| > bugzilla entry
| > 	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
| > 
| > The motivating example, abstracted from a misbehaving part of X, is:
| > 	void test (char *addr) {
| >         	*((volatile char *) addr);
| > 	}
| > In this case, the fetch ("access") is required for the hardware to
| > behave.
| > 
| ...
| 
| > 6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
| > object yields an lvalue of type `T' designating that object.  So the
| > lvalue in the assignment has a volatile-qualified type. 
| > 
| > 6.3.2.1:  when an object is said to have a particular type, the type is
| > specified by the lvalue used to designate the object.  So the lvalue
| > having a volatile-qualified type *means* that the object it designates has
| > a volatile-qualified type; "has type X" and "is designated by an lvalue of
| 
| How does this reasoning not apply to *((char *)a) = 5 where a was
| originally of a const qualified type?
| Or do you think you can only *add* qualifiers, and not remove them?

If by analysis, you can determine that the argument bound to "a"
actually is the address of a const object (not just a plain pointer
that happens to accidently acquire a const), then it effectively is
invoking an undefined behaviour.  Otherwise, GCC has to accept the
cast-away and store 5.  In general, we just store "5", and let user has
its machine blow if the location is actually read only.



Interestingly, C++ uses a slightly different language and formulation
of its object model and type system.  I'm under the impression that in
previous discussions, there were a mixture of both both (C and C++)
models. 


   The constructs in a C++ program create, destroy, refer to,
   access, and manipulate objects. An object is a region of
   storage. [Note: A function is not an object, regardless of whether
   or not it occupies storage in the way that objects do. ] An object
   is created by a definition (3.1), by a new-expression (5.3.4) or by
   the implementation (12.2) when needed. The properties of an object are
   determined when the object is created.  An object can have a name
   (clause 3). An object has a storage duration (3.7) which influences
   its lifetime (3.8). An object has a type (3.9). The term object
   type refers to the type with which the object is created.  Some
   objects are polymorphic (10.3); the implementation generates
   information associated with each such object that makes it possible
   to determine that objects type during program execution. For other
   objects, the interpretation of the values found therein is
   determined by the type of the expressions (clause 5) used to access them.


Here, C++ says that the type of an object is acquired when the object
is created, NOT the type of the lvalue expression used to access it.

Someone allued to the type-based alias analysis, again C++ uses a
slightly different formulation talking about the "dynamic type", which
is well-defined, i.e. the type with which the object was created.
Thus GCC is well-founded there.

| Because if you allow casting away, then you can't ever trust const to be
| true either, just like we apparently can't trust the user saying "this
| is not volatile" (which they are doing by not declaring the original
| object volatile).

Indeed.  We must however make sure we distinguish between the meaning
of  const as in "const T* p" and that of const in "const T".

| There is no point in type qualifiers if they can be simply changed at
| will.  Do not lie about your objects, and you will not be screwed over.

only if the language you're implementing the compiler for says so, no
matter what nifty transformation you could have done.

-- Gaby

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
> Daniel Berlin wrote:
> >>> object volatile).
> >>
> >>
> >> I don't understand your point. given
> >>     void Foo (char const * a) { *(char *)a = 5; }
> >> the compiler generates code to store 5 through the pointer 'a'.  It
> >> doesn't turn
> >> this into a call to 'abort', because it thinks you're writing to const
> >> storage.
> > 
> > 
> > Is this *always* the cast, or just in the example above?
> 
> I thought we were discussing the case where there is no static information about
> what the pointer actually points to. I.e. the case of an incoming pointer
> parameter of a function that is not being inlined (or equivalent).

If so, i  have no problem, but then you end up with people claiming we
shouldn't know info we actually do, etc.

> 
> 
> > It appears he was saying that *even if it could determine the static
> > type*, the volatile qualifier on the cast *made the object not that type
> > anymore*. And i'm not sure why such a thing would apply only to
> > volatile, if true.
> 
> I could not determine whether that was the case of Hugh Redelmeier's argument --
> the example is an incomping pointer parameter.

> 
> I agree with you, Daniel, that if the static object can be determined, then its
> type qualifiers win.
> 
> nathan

Re: volatile semantics

[D. Hugh Redelmeier]

[I'm just a tourist here.  I don't subscribe to the gcc list.  I don't
hack on gcc itself.  I'm just posting because this bug hits me and
didn't seem to be analyzed correctly.  I have participated in the C
standardization process for perhaps 20 years.  Now that I look at the
GCC list archives, I see a more of misunderstanding of the standard
than I'd like.]

| From: Daniel Berlin <dberlin@dberlin.org>

[quoting Henry's comment]

| > 6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
| > object yields an lvalue of type `T' designating that object.  So the
| > lvalue in the assignment has a volatile-qualified type. 
| > 
| > 6.3.2.1:  when an object is said to have a particular type, the type is
| > specified by the lvalue used to designate the object.  So the lvalue
| > having a volatile-qualified type *means* that the object it designates has
| > a volatile-qualified type; "has type X" and "is designated by an lvalue of
| 
| How does this reasoning not apply to *((char *)a) = 5 where a was
| originally of a const qualified type?

Did you read Henry's comment in full?  It specifically addresses
"const".

    Surprising though it might seem, I see no express or implied permission to
    distinguish based on whether the object in question was *defined* with a
    volatile-qualified type.  There are places in the standard where how an
    object is defined is significant, e.g. the rules for `const' and the part
    of 6.7.3 noted in the previous paragraph, but none of them is part of the
    chain of reasoning above.

| Or do you think you can only *add* qualifiers, and not remove them?

No, that was not said.

| Because if you allow casting away, then you can't ever trust const to be
| true either, just like we apparently can't trust the user saying "this
| is not volatile" (which they are doing by not declaring the original
| object volatile).

No, that is not correct reasoning.

"const" says: this lvalue will only be used for reading.  It does not
say that the underlying object will not be changed.  More is implied
if the object in question is *defined* with a const attribute.  For
example:
	const int foo = 0xF00;

| There is no point in type qualifiers if they can be simply changed at
| will.

This has an element of truth to it.  But they do have points:

- const means that a program cannot accidentally change something
  through a const-qualified thingee (lvalue, pointer, whatever)

- volatile tells the compiler "hands off" when such an lvalue is used.

- let's not talk about "restrict"

|  Do not lie about your objects, and you will not be screwed over.

Funny that you should be paraphrasing one of Henry's famous aphorisms
"If you lie to the compiler, it will get its revenge.".  Yes, this is
the same Henry Spencer.

Re: volatile semantics

[Dale Johannesen]

On Jul 16, 2005, at 10:34 AM, Andrew Haley wrote:

>> 6.3.2.1:  when an object is said to have a particular type, the type 
>> is
>> specified by the lvalue used to designate the object.

I don't have a standard here, but I will point out that IF this 
sentence is
interpreted to mean

>  the type of an object
> changes depending on how it is accessed.

this also makes nonsense of gcc's implementation of type-based aliasing
rules.

   *((int *)&x) = 3

would then be valid whatever the type of x.

Re: volatile semantics

[Nathan Sidwell]

Daniel Berlin wrote:
>>> object volatile).
>>
>>
>> I don't understand your point. given
>>     void Foo (char const * a) { *(char *)a = 5; }
>> the compiler generates code to store 5 through the pointer 'a'.  It
>> doesn't turn
>> this into a call to 'abort', because it thinks you're writing to const
>> storage.
> 
> 
> Is this *always* the cast, or just in the example above?

I thought we were discussing the case where there is no static information about
what the pointer actually points to. I.e. the case of an incoming pointer
parameter of a function that is not being inlined (or equivalent).


> It appears he was saying that *even if it could determine the static
> type*, the volatile qualifier on the cast *made the object not that type
> anymore*. And i'm not sure why such a thing would apply only to
> volatile, if true.

I could not determine whether that was the case of Hugh Redelmeier's argument --
the example is an incomping pointer parameter.

I agree with you, Daniel, that if the static object can be determined, then its
type qualifiers win.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Daniel Berlin]

> In other words, we're asked to agree that the type of an object
> changes depending on how it is accessed.
> For the benefit of readers, only the first sentence of this para is
> the language of the standard; the rest isn't.  
> 
> That an object referred to through a volatile pointer must
> "temporarily" be treated as though it were declared volatile is the
> crux of this argument. 

Again, you could say the same about const, restrict, or any other
qualifier then, making them more or less useless as qualifiers.

Re: volatile semantics

[Andrew Haley]

D. Hugh Redelmeier writes:
 > ================ start of Henry Spencer's comment
 > 
 > There is little room for compiler writers to maneuver here, unless they
 > have announced their intentions in advance in their documentation. 
 > Reading C99 carefully:
 > 
 > ...
 > 
 > 6.3.2.1:  when an object is said to have a particular type, the type is
 > specified by the lvalue used to designate the object.  So the lvalue
 > having a volatile-qualified type *means* that the object it designates has
 > a volatile-qualified type; "has type X" and "is designated by an lvalue of
 > type X" are synonymous (!).

In other words, we're asked to agree that the type of an object
changes depending on how it is accessed.

For the benefit of readers, only the first sentence of this para is
the language of the standard; the rest isn't.  

That an object referred to through a volatile pointer must
"temporarily" be treated as though it were declared volatile is the
crux of this argument.  I don't believe that such a conclusion must
necessarily be drawn from this language.  That may well be what the
authors meant, but I don't think that it's certainly so.

Andrew.

Re: volatile semantics

[Daniel Berlin]

>> object volatile).
>
> I don't understand your point. given
> 	void Foo (char const * a) { *(char *)a = 5; }
> the compiler generates code to store 5 through the pointer 'a'.  It doesn't turn
> this into a call to 'abort', because it thinks you're writing to const storage.

Is this *always* the cast, or just in the example above?

>
> So, here it appears the compiler does believe the (char *) cast.

I imagine this is due to some workaround in an optimizer for some bug it 
exposed elswhere.

>  Why should it
> not believe a (char volatile *) cast -- unless it can determine the static type
> of the object pointed to?

It appears he was saying that *even if it could determine the static 
type*, the volatile qualifier on the cast *made the object not that type 
anymore*. And i'm not sure why such a thing would apply only to volatile, 
if true.


--Dan

Re: volatile semantics

[Nathan Sidwell]

Daniel Berlin wrote:

> How does this reasoning not apply to *((char *)a) = 5 where a was
> originally of a const qualified type?
> Or do you think you can only *add* qualifiers, and not remove them?
> 
> Because if you allow casting away, then you can't ever trust const to be
> true either, just like we apparently can't trust the user saying "this
> is not volatile" (which they are doing by not declaring the original
> object volatile).

I don't understand your point. given
	void Foo (char const * a) { *(char *)a = 5; }
the compiler generates code to store 5 through the pointer 'a'.  It doesn't turn
this into a call to 'abort', because it thinks you're writing to const storage.

So, here it appears the compiler does believe the (char *) cast.  Why should it
not believe a (char volatile *) cast -- unless it can determine the static type
of the object pointed to?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Daniel Berlin]

On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
> Sorry for the very late response.  It is actually triggered by the
> bugzilla entry
> 	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
> 
> The motivating example, abstracted from a misbehaving part of X, is:
> 	void test (char *addr) {
>         	*((volatile char *) addr);
> 	}
> In this case, the fetch ("access") is required for the hardware to
> behave.
> 
...

> 6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
> object yields an lvalue of type `T' designating that object.  So the
> lvalue in the assignment has a volatile-qualified type. 
> 
> 6.3.2.1:  when an object is said to have a particular type, the type is
> specified by the lvalue used to designate the object.  So the lvalue
> having a volatile-qualified type *means* that the object it designates has
> a volatile-qualified type; "has type X" and "is designated by an lvalue of

How does this reasoning not apply to *((char *)a) = 5 where a was
originally of a const qualified type?
Or do you think you can only *add* qualifiers, and not remove them?

Because if you allow casting away, then you can't ever trust const to be
true either, just like we apparently can't trust the user saying "this
is not volatile" (which they are doing by not declaring the original
object volatile).

There is no point in type qualifiers if they can be simply changed at
will.  Do not lie about your objects, and you will not be screwed over.

Re: volatile semantics

[D. Hugh Redelmeier]

Sorry for the very late response.  It is actually triggered by the
bugzilla entry
	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278

The motivating example, abstracted from a misbehaving part of X, is:
	void test (char *addr) {
        	*((volatile char *) addr);
	}
In this case, the fetch ("access") is required for the hardware to
behave.

| From: Dale Johannesen <dalej at apple dot com>
| Date: Tue, 3 May 2005 10:04:36 -0700
| 
| On May 3, 2005, at 7:41 AM, Nathan Sidwell wrote:
| > Mike Stump wrote:
| > > int avail;
| > > int main() {
| > >   while (*(volatile int *)&avail == 0)
| > >     continue;
| > >   return 0;
| > > }
| > > Ok, so, the question is, should gcc produce code that infinitely  loops,
| > > or should it be obligated to actually fetch from memory?   Hint, 3.3
| > > fetched.
| > 
| > I beleive the compiler is so licensed. [5.1.2.3/2] talks about accessing
| > a volatile object.  If the compiled can determine the actual object
| > being accessed through a series of pointer and volatile cast conversions,
| > then I see nothing in the std saying it must behave as-if the object
| > were volatile when it is not.

That turns out not to be the case.  See the chain of reasoning later
in this message.

| This is correct; the standard consistently talks about the type of the object,
| not the type of the lvalue, when describing volatile.
|
| 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.

It appears to me that standards conformance requires the access to be
performed.  So GCC4 has a bug.  One that is subtle, so the damage it
is doing may not be evident.  The worst kind.

When I asked Henry Spencer to look at this, he gave a convincing
argument from chapter and verse of C99.  I will quote it here.  I
added the identical text to the bugzilla entry (comment #43), so there
is no need to read the rest of this message if you read that comment.

================ start of Henry's comment

There is little room for compiler writers to maneuver here, unless they
have announced their intentions in advance in their documentation. 
Reading C99 carefully:

6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
object yields an lvalue of type `T' designating that object.  So the
lvalue in the assignment has a volatile-qualified type. 

6.3.2.1:  when an object is said to have a particular type, the type is
specified by the lvalue used to designate the object.  So the lvalue
having a volatile-qualified type *means* that the object it designates has
a volatile-qualified type; "has type X" and "is designated by an lvalue of
type X" are synonymous (!).

6.7.3:  any expression referring to an object of volatile-qualified
type must be evaluated strictly by the rules of the abstract machine,
although precisely what constitutes an "access" to the object is
implementation-defined.  (Note, "implementation-defined" behavior is
required to be well-defined and *documented*.)  So if the reference in
question is an "access", it must occur where the abstract machine says
it should.

5.1.2.3:  the abstract machine evaluates all expressions as specified by
semantics and all side effects must occur, side effects including
"accessing a volatile object"; implementations are allowed to skip part
of expression evaluation only if they can deduce that no needed side
effects (notably "accessing a volatile object") are therefore skipped. 
So if the reference is an "access", it must occur, period.

I see no useful wiggle room in the difference between "access" and
"accessing", or the difference between "volatile object" and "object of
volatile-qualified type".  These appear to me to be minor accidents of
inconsistent terminology, not useful to a sane implementer.

6.7.3 says that to refer to an object "defined with" volatile-qualified
type "through use of an lvalue" with non-volatile-qualified type yields
undefined behavior.  However, the reference here uses a volatile-qualified
lvalue, so this is not relevant.  A pointer value is not an lvalue; there
is no lvalue present until the `*' operator is applied. 

Surprising though it might seem, I see no express or implied permission to
distinguish based on whether the object in question was *defined* with a
volatile-qualified type.  There are places in the standard where how an
object is defined is significant, e.g. the rules for `const' and the part
of 6.7.3 noted in the previous paragraph, but none of them is part of the
chain of reasoning above.

The only loophole is the definition of "access".  If GCC wishes to claim
standard conformance, GCC is required to document its definition.  I'm not
aware of any mention of this in the GCC documentation, although I haven't
dug hard for it. 

I see no room for a reasonable definition of "access" which retains some
useful meaning for `volatile' and doesn't cover the reference in question. 
(I agree that you can contrive a definition which contains special-case
wording to cover this case, but not that it's reasonable to do so.)

If GCC (a) wants to be C99-conforming, and (b) wants to provide useful
semantics for `volatile', this is a bug.

Henry

Re: volatile semantics

[Paul Koning]

>>>>> "Geoffrey" == Geoffrey Keating <geoffk@geoffk.org> writes:

 Geoffrey> Paul Koning <pkoning@equallogic.com> writes:
 >> Still, never mind what the C spec appears to say, optimizing away
 >> the cast cannot possibly what the user intended.

 Geoffrey> The user might have written a routine which takes a
 Geoffrey> 'volatile int *', with the intent that routine would be
 Geoffrey> used on both regular and volatile 'int's.  The compiler
 Geoffrey> might be able to see (after inlining) that this particular
 Geoffrey> instance does not actually refer to a volatile variable,
 Geoffrey> and so be able to optimise the routine better.

Ok, so every once in a while you might run into a case like that, and
you could very slightly speed up that case at the expense of
introducing a hairy bug into all other cases.  Not a good tradeoff at
all.

	paul

Re: volatile semantics

[Geoffrey Keating]

Paul Koning <pkoning@equallogic.com> writes:

> Still, never mind what the C spec appears to say, optimizing away the
> cast cannot possibly what the user intended.

The user might have written a routine which takes a 'volatile int *',
with the intent that routine would be used on both regular and
volatile 'int's.  The compiler might be able to see (after inlining)
that this particular instance does not actually refer to a volatile
variable, and so be able to optimise the routine better.

(This is almost exactly the same argument as for a routine which takes
an 'int *' but gets called with a value cast from 'const int *'.)

Re: volatile semantics

[Paul Schlie]

> Dale Johannesen writes:
>> Nathan Sidwell wrote:
>> Also, I wonder about the following example
>>
>> int const avail = <something>
>>
>> int main() {
>>  while (*(int *)&avail == Foo ())
>>    do_something();
>>  return 0;
>> }
>>
>> Seeing through the const-stripping cast is a useful optimization.
>
> It is? Why would somebody write that?

- It shouldn't mater, GCC should simply treat the outermost cast as the
  effective definition of the qualified access path and type of the object
  referenced within this context. Although it seems very reasonable that a
  cast or parameter specification which results in any qualification being
  dropped, minimally produces a warning, just in case the dropping of the
  qualifier wasn't intended, as simply dropping a const qualifier for
  example does not warrant that object referenced is actually physically
  writable; i.e. for example a static const object may literally be stored
  in ROM, just as array/string, or structure literals may be; just as
  correspondingly dropping an objects volatile qualifier no longer warrants
  that it's logical reference will result in a physically access.

>> A further pathelogical case would be,
>>
>> int main() {
>>  while (*(int *)(volatile int *)&avail)
>>    do_something ();
>>  return 0;
>> }
>>
>> What should this do, treat the volatile qualifier as sticky?
>
> IMO, no, but surely we don't have to worry about this one. Either way
> is standard conformant and the user's intent is far from clear, so whatever
> we do should be OK.

- As above, the object should likely be simply references as if an (int *),
  nothing more nothing less. With a warning that the const qualifier was
  dropped upon a cast to (volatile int *), and that volatile was dropped
  upon it's final cast to (int *).

Re: volatile semantics

[Dale Johannesen]

On May 5, 2005, at 5:23 AM, Kai Henningsen wrote:
> nathan@codesourcery.com (Nathan Sidwell)  wrote on 03.05.05 in 
> <42778D99.7070904@codesourcery.com>:
>> Mike Stump wrote:
>>> int avail;
>>> int main() {
>>>   while (*(volatile int *)&avail == 0)
>>>     continue;
>>>   return 0;
>>> }
>>>
>>>
>>> Ok, so, the question is, should gcc produce code that infinitely  
>>> loops,
>>> or should it be obligated to actually fetch from memory?   Hint, 3.3
>>> fetched.
>>
>> I beleive the compiler is so licensed. [5.1.2.3/2] talks about 
>> accessing
>> a volatile object.  If the compiled can determine the actual object
>> being accessed through a series of pointer and volatile cast 
>> conversions,
>> then I see nothing in the std saying it must behave as-if the object
>> were volatile when it is not.
>>
>> This, of course, might not be useful to users :)
>
> As a QOI issue, it would be nice if such a situation caused a warning
> ("ignoring volatile cast ..." or something like that).
>
> It's rather dangerous to have the user believe that this worked as
> intended when it didn't.

If we aren't going to make this work as obviously intended, and the 
sentiment
seems to be against it, then this is certainly a good idea.

Re: volatile semantics

[Gabriel Dos Reis]

kaih@khms.westfalen.de (Kai Henningsen) writes:

| nathan@codesourcery.com (Nathan Sidwell)  wrote on 03.05.05 in <42778D99.7070904@codesourcery.com>:
| 
| > Mike Stump wrote:
| > > int avail;
| > > int main() {
| > >   while (*(volatile int *)&avail == 0)
| > >     continue;
| > >   return 0;
| > > }
| > >
| > >
| > > Ok, so, the question is, should gcc produce code that infinitely  loops,
| > > or should it be obligated to actually fetch from memory?   Hint, 3.3
| > > fetched.
| >
| > I beleive the compiler is so licensed. [5.1.2.3/2] talks about accessing
| > a volatile object.  If the compiled can determine the actual object
| > being accessed through a series of pointer and volatile cast conversions,
| > then I see nothing in the std saying it must behave as-if the object
| > were volatile when it is not.
| >
| > This, of course, might not be useful to users :)
| 
| As a QOI issue, it would be nice if such a situation caused a warning  
| ("ignoring volatile cast ..." or something like that).

such a warning is fine by me.  Any one care to submit a patch?

-- Gaby

Re: volatile semantics

[Paul Koning]

>>>>> "Kai" == Kai Henningsen <kaih@khms.westfalen.de> writes:

 Kai> As a QOI issue, it would be nice if such a situation caused a
 Kai> warning ("ignoring volatile cast ..." or something like that).

 Kai> It's rather dangerous to have the user believe that this worked
 Kai> as intended when it didn't.

Definitely.  We already have warnings for "this doesn't do what you
thought" -- like "statement has no effect" if you type == where = was
intended.  Ignoring volatile is at least as deserving of a warning,
and probably more so, because the bugs created by that action are more
subtle.

	paul

Re: volatile semantics

[Kai Henningsen]

nathan@codesourcery.com (Nathan Sidwell)  wrote on 03.05.05 in <42778D99.7070904@codesourcery.com>:

> Mike Stump wrote:
> > int avail;
> > int main() {
> >   while (*(volatile int *)&avail == 0)
> >     continue;
> >   return 0;
> > }
> >
> >
> > Ok, so, the question is, should gcc produce code that infinitely  loops,
> > or should it be obligated to actually fetch from memory?   Hint, 3.3
> > fetched.
>
> I beleive the compiler is so licensed. [5.1.2.3/2] talks about accessing
> a volatile object.  If the compiled can determine the actual object
> being accessed through a series of pointer and volatile cast conversions,
> then I see nothing in the std saying it must behave as-if the object
> were volatile when it is not.
>
> This, of course, might not be useful to users :)

As a QOI issue, it would be nice if such a situation caused a warning  
("ignoring volatile cast ..." or something like that).

It's rather dangerous to have the user believe that this worked as  
intended when it didn't.

MfG Kai

Re: volatile semantics

[Nathan Sidwell]

Dale Johannesen wrote:

> Both behaviors are standard-compliant.
I don't think anyone's disagreeing with that.  The point is that the
user *requires* a volatile read, but the std *does not* guarantee it.

 > Treating a reference as volatile when you don't have to just means
 > strictly following the rules of the abstract machine; it can never
 > break anything.

ok then, this can be achieved with the -O0 flag :)  I doubt that's
what is desired though.

> I see a difference between a documented extension, and quietly choosing
> from among standard-compliant behaviors the one which is most convenient 
> for users.

I see your point, but I think it is wrong.  How can the programmer rely
on gcc adhering more strictly to the abstract machine than the std
requires, unless the behaviour is documented?  How can the gcc developers
make sure optimizations are not breaking such a promise, unless it is
documented?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Paul Koning]

>>>>> "Dale" == Dale Johannesen <dalej@apple.com> writes:

 Dale> On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:

 >> Andrew Haley <aph@redhat.com> writes:
 >> 
 >> | Nathan Sidwell writes: | > Dale Johannesen wrote:
 >> |  >
 >> | > > And we don't have to document the behavior at all; it is not
 >> documented | > > now.  | > I disagree.  It's not documented
 >> explicitly in gcc now, because it is doing | > what the std
 >> permits, and so documented there. We should document either
 >> |  >
 >> | > a) that current gcc is not breaking the std, and Mike's
 >> example is invalid | > code, if one expects a volatile read.  This
 >> would be a FAQ like thing.

 Dale> Both behaviors are standard-compliant.  Treating a reference as
 Dale> volatile when you don't have to just means strictly following
 Dale> the rules of the abstract machine; it can never break anything.

 >> I vote for (a).
 >> 
 >> [...]
 >> 
 >> | This is a bad extension to gcc and will cause much trouble, just
 >> like | the old guarantee to preserve empty loops.

 Dale> I see a difference between a documented extension, and quietly
 Dale> choosing from among standard-compliant behaviors the one which
 Dale> is most convenient for users.

I agree, but I would put it more strongly -- choose the interpretation
which (a) satisfies the principle of least astonishment, (b) matches
previous version behavior, and (c) will keep existing user code
working rather than breaking it in hard to debug ways.

	paul

Re: volatile semantics

[Dale Johannesen]

On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:

> Andrew Haley <aph@redhat.com> writes:
>
> | Nathan Sidwell writes:
> |  > Dale Johannesen wrote:
> |  >
> |  > > And we don't have to document the behavior at all; it is not 
> documented
> |  > > now.
> |  > I disagree.  It's not documented explicitly in gcc now, because 
> it is doing
> |  > what the std permits, and so documented there. We should document 
> either
> |  >
> |  > a) that current gcc is not breaking the std, and Mike's example 
> is invalid
> |  > code, if one expects a volatile read.  This would be a FAQ like 
> thing.

Both behaviors are standard-compliant.  Treating a reference as 
volatile when
you don't have to just means strictly following the rules of the 
abstract machine;
it can never break anything.

> I vote for (a).
>
> [...]
>
> | This is a bad extension to gcc and will cause much trouble, just like
> | the old guarantee to preserve empty loops.

I see a difference between a documented extension, and quietly choosing
from among standard-compliant behaviors the one which is most 
convenient for
users.

Re: volatile semantics

[Gabriel Dos Reis]

Andrew Haley <aph@redhat.com> writes:

| Nathan Sidwell writes:
|  > Dale Johannesen wrote:
|  > 
|  > > And we don't have to document the behavior at all; it is not documented 
|  > > now.
|  > I disagree.  It's not documented explicitly in gcc now, because it is doing
|  > what the std permits, and so documented there. We should document either
|  > 
|  > a) that current gcc is not breaking the std, and Mike's example is invalid
|  > code, if one expects a volatile read.  This would be a FAQ like thing.

I vote for (a).

[...]

| This is a bad extension to gcc and will cause much trouble, just like
| the old guarantee to preserve empty loops.

Hear, hear, hear.

-- Gaby

Re: volatile semantics

[Andrew Haley]

Nathan Sidwell writes:
 > Dale Johannesen wrote:
 > 
 > > And we don't have to document the behavior at all; it is not documented 
 > > now.
 > I disagree.  It's not documented explicitly in gcc now, because it is doing
 > what the std permits, and so documented there. We should document either
 > 
 > a) that current gcc is not breaking the std, and Mike's example is invalid
 > code, if one expects a volatile read.  This would be a FAQ like thing.
 > 
 > b) amend the compiler to do a volatile read, and document the extension.
 > This should go in extend.texi
 > 
 > Documentation for (b) is necessary so that programmers can rely on the
 > extension (and understand why some other compiler might not do what they
 > want) _and_ so that gcc maintainers know about it.

And it is difficult to specify exactly where volatile casts should be
preserved and where they may legitimately be optimized away, so we may
well make mistakes in doing so, and end up with an ill-defined
extension.  The C Standard already has well-defined semantics for
this, and we are not AFAIAA in the business of redesigning C.  What
matters is the volatility of the _object_, and this is at least
reasonably easy to understand.

This is a bad extension to gcc and will cause much trouble, just like
the old guarantee to preserve empty loops.

Andrew.

Re: volatile semantics

[Nathan Sidwell]

Dale Johannesen wrote:

> And we don't have to document the behavior at all; it is not documented 
> now.
I disagree.  It's not documented explicitly in gcc now, because it is doing
what the std permits, and so documented there. We should document either

a) that current gcc is not breaking the std, and Mike's example is invalid
code, if one expects a volatile read.  This would be a FAQ like thing.

b) amend the compiler to do a volatile read, and document the extension.
This should go in extend.texi

Documentation for (b) is necessary so that programmers can rely on the
extension (and understand why some other compiler might not do what they
want) _and_ so that gcc maintainers know about it.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Thorsten Glaser]

Mike Stump dixit:

> int avail;
> int main() {
>  while (*(volatile int *)&avail == 0)
>    continue;
>  return 0;
> }

3.4.4 fetches too. I get:

.L2:
        mov     %eax, DWORD PTR avail
        test    %eax, %eax
        je      .L2

This is at -O99, other levels produce similar results.

//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: volatile semantics

[Dale Johannesen]

On May 3, 2005, at 11:52 AM, Nathan Sidwell wrote:

> Dale Johannesen wrote:
>> On May 3, 2005, at 11:03 AM, Nathan Sidwell wrote:
>
>>> Seeing through the const-stripping cast is a useful optimization.
>> It is?  Why would somebody write that?
>
> perhaps a function, which returned a non-const reference that
> happened to be bound to a constant, has been inlined.

OK, I agree.

>> IMO, no, but surely we don't have to worry about this one.  Either way
>> is standard conformant and the user's intent is far from clear, so 
>> whatever
>> we do should be OK.
>
> If we guarantee one to work and not the other, we need to have a clear
> specification of how they differ.  What if intermediate variables -- 
> either
> explicit in the program, or implicitly during the optimization -- get
> introduced?
>
> My guess is that the wording of the standard might be the best that
> could be achieved in this regard.  It would be nice to have some clear
> wording indicating that Mike's example will work, but some other, 
> possibly
> closely related, example will not.

It's not that bad; the type of an lvalue is already well defined (it is 
"int" in
your last example, and "volatile int" in Mike's).  We just take this 
type into
account in determining whether a reference is to be treated as volatile.
(Which means we need to keep track of, or at least be able to find, both
the type of the lvalue and the type of the underlying object.  As you 
say,
gcc may have some implementation issues with this.)

And we don't have to document the behavior at all; it is not documented 
now.

Re: volatile semantics

[Nathan Sidwell]

Dale Johannesen wrote:
> On May 3, 2005, at 11:03 AM, Nathan Sidwell wrote:

>> Seeing through the const-stripping cast is a useful optimization.
> 
> 
> It is?  Why would somebody write that?

perhaps a function, which returned a non-const reference that
happened to be bound to a constant, has been inlined.

> IMO, no, but surely we don't have to worry about this one.  Either way
> is standard conformant and the user's intent is far from clear, so whatever
> we do should be OK.

If we guarantee one to work and not the other, we need to have a clear
specification of how they differ.  What if intermediate variables -- either
explicit in the program, or implicitly during the optimization -- get
introduced?

My guess is that the wording of the standard might be the best that
could be achieved in this regard.  It would be nice to have some clear
wording indicating that Mike's example will work, but some other, possibly
closely related, example will not.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Dale Johannesen]

On May 3, 2005, at 11:21 AM, Paul Koning wrote:
> This change bothers me a lot.  It seems likely that this will break
> existing code possibly in subtle ways.

It did, that is why Mike is asking about it. :)

Re: volatile semantics

[Dale Johannesen]

On May 3, 2005, at 11:03 AM, Nathan Sidwell wrote:
> 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.
>
> I'm not disagreeing with you, but I wonder at gcc's ability to make
> good on such a promise.  A cast introducing a volatile qualifier
> will be a NOP_EXPR, and gcc tends to strip those at every opportunity.

You may well be right, I haven't tried to implement it (and am not 
planning to).

> Also, I wonder about the following example
>
> int const avail = <something>
>
> int main() {
>   while (*(int *)&avail == Foo ())
>     do_something();
>   return 0;
> }
>
> Seeing through the const-stripping cast is a useful optimization.

It is?  Why would somebody write that?

> A further pathelogical case would be,
>
> int main() {
>   while (*(int *)(volatile int *)&avail)
>     do_something ();
>   return 0;
> }
>
> What should this do, treat the volatile qualifier as sticky?

IMO, no, but surely we don't have to worry about this one.  Either way
is standard conformant and the user's intent is far from clear, so 
whatever
we do should be OK.

Re: volatile semantics

[Paul Koning]

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

Re: volatile semantics

[Nathan Sidwell]

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.

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

Also, I wonder about the following example

int const avail = <something>

int main() {
   while (*(int *)&avail == Foo ())
     do_something();
   return 0;
}

Seeing through the const-stripping cast is a useful optimization. We'd
have to have one rule for adding volatile and a different one for removing
const.

A further pathelogical case would be,

int main() {
   while (*(int *)(volatile int *)&avail)
     do_something ();
   return 0;
}

What should this do, treat the volatile qualifier as sticky?


nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Dale Johannesen]

On May 3, 2005, at 7:41 AM, Nathan Sidwell wrote:
> Mike Stump wrote:
>> int avail;
>> int main() {
>>   while (*(volatile int *)&avail == 0)
>>     continue;
>>   return 0;
>> }
>> Ok, so, the question is, should gcc produce code that infinitely  
>> loops, or should it be obligated to actually fetch from memory?   
>> Hint, 3.3 fetched.
>
> I beleive the compiler is so licensed. [5.1.2.3/2] talks about 
> accessing
> a volatile object.  If the compiled can determine the actual object
> being accessed through a series of pointer and volatile cast 
> conversions,
> then I see nothing in the std saying it must behave as-if the object
> were volatile when it is not.

This is correct; the standard consistently talks about the type of the 
object,
not the type of the lvalue, when describing volatile.

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.

Re: volatile semantics

[Nathan Sidwell]

Mike Stump wrote:
> int avail;
> int main() {
>   while (*(volatile int *)&avail == 0)
>     continue;
>   return 0;
> }
> 
> 
> Ok, so, the question is, should gcc produce code that infinitely  loops, 
> or should it be obligated to actually fetch from memory?   Hint, 3.3 
> fetched.

I beleive the compiler is so licensed. [5.1.2.3/2] talks about accessing
a volatile object.  If the compiled can determine the actual object
being accessed through a series of pointer and volatile cast conversions,
then I see nothing in the std saying it must behave as-if the object
were volatile when it is not.

This, of course, might not be useful to users :)

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

RE: volatile semantics

[Dave Korn]

----Original Message----
>From: Mike Stump
>Sent: 03 May 2005 09:42

> int avail;
> int main() {
>    while (*(volatile int *)&avail == 0)
>      continue;
>    return 0;
> }
> 
> 
> Ok, so, the question is, should gcc produce code that infinitely
> loops, or should it be obligated to actually fetch from memory?
> Hint, 3.3 fetched.
> 
> 
> I get:
> 
> L6:
>          b L6
> 
> on mainline and 4.0.

  Any difference if you change the function name from 'main' to something
else?

  And what happens if you precede the while line with

extern void foo (int *);

    foo (&avail);

or indeed what happens if you replace the definition of avail with an extern
declaration?

extern int avail;

(you'd need to link with another module that actually instantiates it of
course).

  Theoretically gcc could know that even though avail is volatile, its
address has never been taken (since here we are right at the beginning of
main), and since it's a compiler-allocated variable rather than referencing
some external location, there is no other way that it could be written into
or read from except through a pointer, and thus it really really really
isn't going to change.  In terms of language-lawyerlyness, you could argue
that the fact that the address is never taken means that any volatile
changes would not come  under the "externally visible" criterion...

  I agree that it should probably be prevented from losing the load, even if
it is a deliberate optimisation rather than a bug, but as far as I can see,
the only time this would crop up would be when you were dealing with flag
variables of the sort that are only meant to be set by running the
application under a debugger and manually storing values into them.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: volatile semantics

[Giovanni Bajo]

Mike Stump <mrs@apple.com> wrote:

> int avail;
> int main() {
>    while (*(volatile int *)&avail == 0)
>      continue;
>    return 0;
> }
>
>
> Ok, so, the question is, should gcc produce code that infinitely
> loops, or should it be obligated to actually fetch from memory?
> Hint, 3.3 fetched.


I agree it should fetch. Did you try -fno-strict-aliasing? Open a bugreport,
I'd say.

Giovanni Bajo

Re: volatile semantics

[Paolo Bonzini]

> Ok, so, the question is, should gcc produce code that infinitely  loops, 
> or should it be obligated to actually fetch from memory?   Hint, 3.3 
> fetched.

IANA(Language)L, but I think it should definitely fetch from memory.

Paolo

volatile semantics

[Mike Stump]

int avail;
int main() {
   while (*(volatile int *)&avail == 0)
     continue;
   return 0;
}


Ok, so, the question is, should gcc produce code that infinitely  
loops, or should it be obligated to actually fetch from memory?   
Hint, 3.3 fetched.


I get:

L6:
         b L6

on mainline and 4.0.