[Bug tree-optimization/21568] New: [3.4 regression] Casts in folding *& omitted

[Bug tree-optimization/21568] New: [3.4 regression] Casts in folding *& omitted

[rguenth at gcc dot gnu dot org]

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

-- 
           Summary: [3.4 regression] Casts in folding *& omitted
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-14 16:32 -------
This is undefined, see the full discussion on the gcc list:
http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.4 regression] Casts in   |[4.0/4.1 regression] Casts
                   |folding *& omitted          |in folding *& omitted


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-05-21 13:50 -------
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;
}


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-05-21 17:31 -------
(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.)


-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[debian-gcc at lists dot debian dot org]

------- Additional Comments From debian-gcc at lists dot debian dot org  2005-05-21 18:10 -------
(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



-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-05-21 20:48 -------
(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?



-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-02 16:48 -------
*** Bug 22278 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olivier dot baudron at m4x
                   |                            |dot org


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[gcc2eran at tromer dot org]

------- Additional Comments From gcc2eran at tromer dot org  2005-07-03 04:55 -------
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
----------------

-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-03 05:52 -------
  *outside = &avail; 

Because at this point avail is known not to volatile.  Did you read what was writting in comment #1 and 
#4?

-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[gcc2eran at tromer dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]


------- Additional Comments From gcc2eran at tromer dot org  2005-07-03 06:50 -------
> 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.

-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[gcc2eran at tromer dot org]

------- Additional Comments From gcc2eran at tromer dot org  2005-07-03 12:12 -------
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!

-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-07-03 17:33 -------
(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.


-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[gcc2eran at tromer dot org]

------- Additional Comments From gcc2eran at tromer dot org  2005-07-06 18:42 -------
Correction of typo in comment 9: the related PR referenced is PR 22278.

-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[wilson at specifix dot com]

------- Additional Comments From wilson at specifix dot com  2005-07-08 00:41 -------
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."


-- 


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

[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

[gcc2eran at tromer dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]


------- Additional Comments From gcc2eran at tromer dot org  2005-07-08 09:18 -------
(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".


-- 


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