[Bug rtl-optimization/21402] New: wrong-code with inlining and type-punned pointer

[Bug rtl-optimization/21402] New: wrong-code with inlining and type-punned pointer

[gcc at arbruijn dot dds dot nl]

The attached C source gives wrong output when compiled with inlined functions
(-O3 or -O2 -finline-functions) with gcc-4.1-20050501 or gcc-4.0.0. Compiling
gives the following warning twice:
dereferencing type-punned pointer will break strict-aliasing rules

The expected output is 0 0, the actual output is two large values. Without
inlined functions or with the unsigned char pointers changed to char pointers
the problem disappears.

There seem to be two problems. One seems to be using an uninitialised stack
value for the pointer which should be initialized to the empty string. The other
seems to be that a pointer (the p2 pointer in the findlast function in the first
inlined readlen call) is modified in a register and is not written back to the
stack before it is read from the stack (to calculate the return value).

On (RedHat modified) gcc 3.4 the output is 0 -1 (it has only the second problem)
and in the actual application there was no problem with gcc 3.3 and before.

-- 
           Summary: wrong-code with inlining and type-punned pointer
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gcc at arbruijn dot dds dot nl
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[gcc at arbruijn dot dds dot nl]

------- Additional Comments From gcc at arbruijn dot dds dot nl  2005-05-05 15:38 -------
Created an attachment (id=8825)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8825&action=view)
C source exposing problem


-- 


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 16:13 -------
"unsigned char *" and "char *" are in two different aliasing sets while char and unsigned char are in the 
same one, well char is every aliasing set.

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


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-05-05 17:19 -------
(In reply to comment #2)
> "unsigned char *" and "char *" are in two different aliasing sets while char
> and unsigned char are in the same one, well char is every aliasing set.

Then I can't help but wonder if it may make sense to reconsider placing
char *, and (un)signed char * in different aliasing sets, as there seems
little if any justifiable reason to generate incorrect code for references to
types which are considered be compatible for assignment. (Just as arguably
it likely makes little sense to generate warnings for the comparison between
pointers to types which differ only in signness for the same reason). As
neither seem particularly useful, and the former is clearly needlessly
potentially dangerious.


-- 


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

Re: [Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[Andrew Pinski]

On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote:

>
> ------- Additional Comments From schlie at comcast dot net  2005-05-05 
> 17:19 -------
> (In reply to comment #2)
>> "unsigned char *" and "char *" are in two different aliasing sets 
>> while char
>> and unsigned char are in the same one, well char is every aliasing 
>> set.
>
> Then I can't help but wonder if it may make sense to reconsider placing
> char *, and (un)signed char * in different aliasing sets, as there 
> seems
> little if any justifiable reason to generate incorrect code for 
> references to
> types which are considered be compatible for assignment. (Just as 
> arguably
> it likely makes little sense to generate warnings for the comparison 
> between
> pointers to types which differ only in signness for the same reason). 
> As
> neither seem particularly useful, and the former is clearly needlessly
> potentially dangerious.

Because this is what the standard says is allowed.  The standard also
says the comparisons and assignment between pointers without a case is
invalid code and should be diagnostic.  Again this is what the standard
says for these things and GCC follows the C standard.

-- Pinski

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-05-05 18:41 -------
Subject: Re:  wrong-code with inlining and type-punned pointer


On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote:

>
> ------- Additional Comments From schlie at comcast dot net  2005-05-05 
> 17:19 -------
> (In reply to comment #2)
>> "unsigned char *" and "char *" are in two different aliasing sets 
>> while char
>> and unsigned char are in the same one, well char is every aliasing 
>> set.
>
> Then I can't help but wonder if it may make sense to reconsider placing
> char *, and (un)signed char * in different aliasing sets, as there 
> seems
> little if any justifiable reason to generate incorrect code for 
> references to
> types which are considered be compatible for assignment. (Just as 
> arguably
> it likely makes little sense to generate warnings for the comparison 
> between
> pointers to types which differ only in signness for the same reason). 
> As
> neither seem particularly useful, and the former is clearly needlessly
> potentially dangerious.

Because this is what the standard says is allowed.  The standard also
says the comparisons and assignment between pointers without a case is
invalid code and should be diagnostic.  Again this is what the standard
says for these things and GCC follows the C standard.

-- Pinski



-- 


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-05-21 21:28 -------
(In reply to comment #4)
> Subject: Re:  wrong-code with inlining and type-punned pointer
> Because this is what the standard says is allowed.  The standard also
> says the comparisons and assignment between pointers without a case is
> invalid code and should be diagnostic.  Again this is what the standard
> says for these things and GCC follows the C standard.

Here's an interesting portion of the standard, which seems to direcly imply
that signed and unsigned lvalue references are presumed to validly alias; so
so this should place both in the same alias set, and potentially eliminate the
default warning when comparing pointers which differ only in signness, as
it seems a little silly if they may factually alias each other:

6.3  Expressions

       [#7] An object shall have its stored value accessed only  by
       an lvalue expression that has one of the following types:59

          - a type  compatible  with  the  effective  type  of  the
            object,

          - a qualified version  of  a  type  compatible  with  the
            effective type of the object,

           - a  type  that  is  the   signed   or   unsigned   type
            corresponding to the effective type of the object,

           - a  type  that  is  the   signed   or   unsigned   type
            corresponding  to  a qualified version of the effective

       __________

       59. The   intent   of   this   list   is  to  specify  those
           circumstances in which an  object  may  or  may  not  be
           aliased.


-- 


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

Re: [Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[Gabriel Dos Reis]

"schlie at comcast dot net" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #4)
| > Subject: Re:  wrong-code with inlining and type-punned pointer
| > Because this is what the standard says is allowed.  The standard also
| > says the comparisons and assignment between pointers without a case is
| > invalid code and should be diagnostic.  Again this is what the standard
| > says for these things and GCC follows the C standard.
| 
| Here's an interesting portion of the standard, which seems to direcly imply
| that signed and unsigned lvalue references are presumed to validly alias; so
| so this should place both in the same alias set, and potentially eliminate the
| default warning when comparing pointers which differ only in signness, as

Sorry, I don't see that implication.  However, GCC already has a
switch for tuning off such comparison.

-- Gaby

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-05-21 21:42 -------
Subject: Re:  wrong-code with inlining and type-punned pointer

"schlie at comcast dot net" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #4)
| > Subject: Re:  wrong-code with inlining and type-punned pointer
| > Because this is what the standard says is allowed.  The standard also
| > says the comparisons and assignment between pointers without a case is
| > invalid code and should be diagnostic.  Again this is what the standard
| > says for these things and GCC follows the C standard.
| 
| Here's an interesting portion of the standard, which seems to direcly imply
| that signed and unsigned lvalue references are presumed to validly alias; so
| so this should place both in the same alias set, and potentially eliminate the
| default warning when comparing pointers which differ only in signness, as

Sorry, I don't see that implication.  However, GCC already has a
switch for tuning off such comparison.

-- Gaby


-- 


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-05-21 22:28 -------
(In reply to comment #6)
> Subject: Re:  wrong-code with inlining and type-punned pointer
> 
> Sorry, I don't see that implication.  However, GCC already has a
> switch for tuning off such comparison.

- Then what is the purpose of the this portion of the standard, if
   not to clarify the intent that lvalues which only differ in signness
   or otherwise compatible qualifications may validly alias each other?

  (this is an honest question, I'm not trying to be difficult)


-- 


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

Re: [Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[Andrew Pinski]

On May 21, 2005, at 6:28 PM, schlie at comcast dot net wrote:

>
> ------- Additional Comments From schlie at comcast dot net  2005-05-21 
> 22:28 -------
> (In reply to comment #6)
>> Subject: Re:  wrong-code with inlining and type-punned pointer
>>
>> Sorry, I don't see that implication.  However, GCC already has a
>> switch for tuning off such comparison.
>
> - Then what is the purpose of the this portion of the standard, if
>    not to clarify the intent that lvalues which only differ in signness
>    or otherwise compatible qualifications may validly alias each other?
>
>   (this is an honest question, I'm not trying to be difficult)

unsigned and signed types are already in the same aliasing set.
Just their pointers are in different aliasing set as allowed by the
standard and this is where the problem is in the code in this bug.

Thanks,
Andrew Pinski

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-05-21 22:32 -------
Subject: Re:  wrong-code with inlining and type-punned pointer


On May 21, 2005, at 6:28 PM, schlie at comcast dot net wrote:

>
> ------- Additional Comments From schlie at comcast dot net  2005-05-21 
> 22:28 -------
> (In reply to comment #6)
>> Subject: Re:  wrong-code with inlining and type-punned pointer
>>
>> Sorry, I don't see that implication.  However, GCC already has a
>> switch for tuning off such comparison.
>
> - Then what is the purpose of the this portion of the standard, if
>    not to clarify the intent that lvalues which only differ in signness
>    or otherwise compatible qualifications may validly alias each other?
>
>   (this is an honest question, I'm not trying to be difficult)

unsigned and signed types are already in the same aliasing set.
Just their pointers are in different aliasing set as allowed by the
standard and this is where the problem is in the code in this bug.

Thanks,
Andrew Pinski



-- 


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-05-21 23:31 -------
(In reply to comment #8)
> Subject: Re:  wrong-code with inlining and type-punned pointer
> > - Then what is the purpose of the this portion of the standard, if
> >    not to clarify the intent that lvalues which only differ in signness
> >    or otherwise compatible qualifications may validly alias each other?
> >
> >   (this is an honest question, I'm not trying to be difficult)
> 
> unsigned and signed types are already in the same aliasing set.
> Just their pointers are in different aliasing set as allowed by the
> standard and this is where the problem is in the code in this bug.

- Thank you, although have to confess that it still eludes me how it's
   logically consistent that an object may be aliased through two different
   pointers which differ only in the signness of the objects they are
   specified to reverence, yet can't themselves be aliased by two different
   pointers which only differ in the signness of the of the dereferenced
   type they point to (since it would seem if X may be aliased by either
   *A or *B, and that *A' may alias A, and *B' may alias B; Then is seems
   to naturally follow that **A' and **B' may both correspondingly alias X;
   therefore it would seem A and B must also be considered to be in the same
   alias set, as otherwise the alias analysis fails to recognize this valid
   possibility, which is the reason the code seems to be miss-compiled)?


-- 


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 09:21 -------
Reopening to ...

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


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 09:21 -------
Mark as a dup of bug 21920.

*** This bug has been marked as a duplicate of 21920 ***

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


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