User account creation filtered due to spam.

Bug 21568 - [4.0/4.1 regression] Casts in folding *& omitted
Summary: [4.0/4.1 regression] Casts in folding *& omitted
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-14 14:09 UTC by Richard Biener
Modified: 2005-07-23 22:49 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2005-05-14 14:09:43 UTC
For the testcase

int x;
int foo(void)
{
        x = 0;
        return *(volatile int *)&x;
}

the tree-optimizers omit the volatile cast and cprop 0 to the
return statement which is invalid.  This is a regression from
3.4 where we produced (with -O)

foo:
        pushl   %ebp
        movl    %esp, %ebp
        movl    $0, x
        movl    x, %eax
        popl    %ebp
        ret

and now

foo:
        pushl   %ebp
        movl    %esp, %ebp
        movl    $0, x
        movl    $0, %eax
        popl    %ebp
        ret
Comment 1 Andrew Pinski 2005-05-14 16:32:14 UTC
This is undefined, see the full discussion on the gcc list:
http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html
Comment 2 Richard Biener 2005-05-21 13:50:46 UTC
The only construct I can make gcc deal with mixed (non-)volatile qualifiers
is a union like in

union {
  volatile int x;
  int y;
} u;
int foo(void)
{
        u.y = 0;
        return u.x;
}
Comment 3 Paul Schlie 2005-05-21 17:31:14 UTC
(In reply to comment #1)
> This is undefined, see the full discussion on the gcc list:
> http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html

- out of curiosity, it's not clear that the discussion reached any
   conclusion which enables GCC to disreguard the type semantics
   as specifed by the program code.  Where in the standard does it
   specify that a type qualifier may be disreguarded if convenient?

   (candidly, I would have exected the specifed rvalue reference to
    x to force x's logical value into memory if not previously done,
    and then subsequently re-accessed to satisfy the union of both
    semantic interpretations.)
Comment 4 Debian GCC Maintainers 2005-05-21 18:10:19 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > This is undefined, see the full discussion on the gcc list:
> > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html
> 
> - out of curiosity, it's not clear that the discussion reached any
>    conclusion which enables GCC to disreguard the type semantics
>    as specifed by the program code.  Where in the standard does it
>    specify that a type qualifier may be disreguarded if convenient?

See http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html

Comment 5 Paul Schlie 2005-05-21 20:48:40 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > This is undefined, see the full discussion on the gcc list:
> > > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html
> > 
> > - out of curiosity, it's not clear that the discussion reached any
> >    conclusion which enables GCC to disreguard the type semantics
> >    as specifed by the program code.  Where in the standard does it
> >    specify that a type qualifier may be disreguarded if convenient?
> 
> See http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html

Thanks for the reference, I reviewed it and agree, but not for the reason
stated. It has nothing to do with the declared type of the object, as a
volatile qualified lvalue reference requires the object be accessed as
a volatile, but may be fully optimized away iff it can be "deduced" that
its omission would have no effect on the program's behavior.

This was only reasonable to "deduce" because the objects address was not
itself a literal address, or assigned to a volatile reference either directly or
indirectly through a potential alias (as doing so would have extended the
visibility of the object beyond the program itself, thereby requiring that the
specified volatile access semantics be retained).

In other words, in the following program variants, the specified volatile
access could not have been optimized away:

---

int avail;                     

(volatile int *)0x0123 = &avail; // because it's value is now potentially
                                 // modifiable external to the program.
int main() {
  while (*(volatile int *)&avail == 0)
    continue;
  return 0;
}

---

int *avail = (int *)0x0ABC;   // as above, it's allocated location isn't private.

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

---

Thanks, If this is what GCC formally does, it would be nice to see it documented?

Comment 6 Andrew Pinski 2005-07-02 16:48:38 UTC
*** Bug 22278 has been marked as a duplicate of this bug. ***
Comment 7 gcc2eran 2005-07-03 04:55:11 UTC
Why was this bug closed? The testcases in comment 5 do *not* pass.

Here's the first testcase, fixed to compile cleanly:

----------------
int avail;

int main() {
  volatile int **outside = (volatile int**)0x0123;
  *outside = &avail; 
  // avail is now potentially modifiable externally to the program
  while (*(volatile int *)&avail == 0)
    continue;
  return 0;
}
----------------

Following the reasoning of comment 5, the read in the loop must not be optimized
away. Still, gcc 4.0.0 with -O3 produces this:

----------------
...
        movl    $avail, 291
        movl    avail, %eax
        testl   %eax, %eax
        je      .L5
        xorl    %eax, %eax
        leave
        ret
.L5:
        jmp     .L5
----------------
Comment 8 Andrew Pinski 2005-07-03 05:52:07 UTC
  *outside = &avail; 

Because at this point avail is known not to volatile.  Did you read what was writting in comment #1 and 
#4?
Comment 9 gcc2eran 2005-07-03 06:50:19 UTC
> Did you read what was writting in comment #1 and #4?

Carefully. Similarly to Paul Schlie in comment 5, I don't agree. My reasoning
follows.


> Because at this point avail is known not to volatile.  

That is irrelevant. According to the standard, all that matters is whether
*(volatile int *)&avail has a volatile-qualified type, which it does. Please
bear with me as I repeat the argument from PR 22267 comment 23, quoting N1124:

"[6.7.3/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, as described in 5.1.2.3. [...]"

All other references to the semantics of volatile likewise talk about "objects",
so let's look up their definition:

"[3.15/1] object: region of data storage in the execution environment, the
contents of which can represent values"
"[3.15/2] NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1."

And here comes the punchline: what is the type of an object?

"[6.3.2.1/1] [...] When an object is said to have a particular type, the type is
specified by the lvalue used to designate the object. [...]"

And also, later on:

"[6.5.3.2/4] The unary * operator denotes indirection. If the operand [...]
points to an object, the result is an lvalue designating the
object. If the operand has type ‘‘pointer to type’’, the result has type
‘‘type’’. [...]"

And just to be sure about whether "volatile" is part of the type thus specified
by the lvalue:

"[6.2.5/26] [...] The qualified or unqualified versions of a type are distinct
types [...]."


Hence, any access to an lvalue whose type is volatile-qualified must be
evaluated strictly according to the rules of the abstract machine. So the
semantics are completely local, caring only about the type of the lvalue. The
type using which the "actual object" being dereferenced was originally defined
is irrelevant.
Comment 10 gcc2eran 2005-07-03 12:12:46 UTC
To make it easier to evaluate my claim, here are all messages in the thread
linked from comment 1 that seemingly contradicy comment 9:

Nathan Sidwell: http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html
Dale Johannesen: http://gcc.gnu.org/ml/gcc/2005-05/msg00090.html
Andrew Haley: http://gcc.gnu.org/ml/gcc/2005-05/msg00144.html

All of these, I am sorry to say, misinterpret the standard since they
misconstrue the meaning of the term "object" in the C type system. They assume
that the object's type is determined by the way it was created (which is indeed
the usual meaning in other languages), whereas the standard quite clearly
defines an object's type to be determined by the lvalue referencing it.

To give one example of this confusion, here is what Dale Johannesen said:
  "the standard consistently talks about the type of the object,
  not the type of the lvalue, when describing volatile."
And here is what N1124 [6.3.2.1/1] says:
  "When an object is said to have a particular type, the type is
   specified by the lvalue used to designate the object."
See my point?

I admit to earning my language lawyer diploma on languages other than C, but the
evidence in comment 9 seems very firm to me. Does anyone see any flaw in it? If
not, then shouldn't this bug be reopened?

Hey, we should be *happy* that we found a standard-compliance excluse to fix the
code-breaking regression and make those casts work like everybody wanted!
Comment 11 Paul Schlie 2005-07-03 17:33:18 UTC
(In reply to comment #10)
> Hey, we should be *happy* that we found a standard-compliance excluse to fix the
> code-breaking regression and make those casts work like everybody wanted!

- I couldn't more strongly agree.
Comment 12 gcc2eran 2005-07-06 18:42:21 UTC
Correction of typo in comment 9: the related PR referenced is PR 22278.
Comment 13 wilson@specifix.com 2005-07-08 00:41:01 UTC
Subject: Re:  [4.0/4.1 regression] Casts in folding
 *& omitted

gcc2eran at tromer dot org wrote:
> And here is what N1124 [6.3.2.1/1] says:
>   "When an object is said to have a particular type, the type is
>    specified by the lvalue used to designate the object."
> See my point?

In the C99 standard, 6.5.4 Cast Operators, Footnote 85 "A cast does not 
yield an lvalue.  Thus, a cast to a qualified type has the same effect 
as a cast to the unqualified version of the type."
Comment 14 gcc2eran 2005-07-08 09:18:34 UTC
(In reply to comment #13)
> In the C99 standard, 6.5.4 Cast Operators, Footnote 85 "A cast does not 
> yield an lvalue.  Thus, a cast to a qualified type has the same effect 
> as a cast to the unqualified version of the type."

But the object being accessed is the one designated by *dereferencing* the cast
expression, and *that* is an lvalue. Quoting N1124:

"[6.5.3.2/4] The unary * operator denotes indirection. If the operand [...]
points to an object, the result is an lvalue designating the
object. If the operand has type ‘‘pointer to type’’, the result has type
‘‘type’’."

And of course:

"[6.5.4/2] Preceding an expression by a parenthesized type name converts the
value of the expression to the named type. [...]"

I think this answers the first half of your quote (i.e., footnote 86), but I'm
not sure what to make of the second half, especially in light of the "Thus".