Bug 21402 - wrong-code with inlining and type-punned pointer
wrong-code with inlining and type-punned pointer
Status: RESOLVED DUPLICATE of bug 21920
Product: gcc
Classification: Unclassified
Component: rtl-optimization
4.1.0
: P2 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-05 15:35 UTC by Arne de Bruijn
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
C source exposing problem (531 bytes, text/plain)
2005-05-05 15:38 UTC, Arne de Bruijn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arne de Bruijn 2005-05-05 15:35:23 UTC
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.
Comment 1 Arne de Bruijn 2005-05-05 15:38:04 UTC
Created attachment 8825 [details]
C source exposing problem
Comment 2 Andrew Pinski 2005-05-05 16:13:10 UTC
"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.
Comment 3 Paul Schlie 2005-05-05 17:19:17 UTC
(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.
Comment 4 Andrew Pinski 2005-05-05 18:41:39 UTC
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

Comment 5 Paul Schlie 2005-05-21 21:28:24 UTC
(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.
Comment 6 Gabriel Dos Reis 2005-05-21 21:42:19 UTC
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
Comment 7 Paul Schlie 2005-05-21 22:28:54 UTC
(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)
Comment 8 Andrew Pinski 2005-05-21 22:32:42 UTC
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

Comment 9 Paul Schlie 2005-05-21 23:31:06 UTC
(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)?
Comment 10 Andrew Pinski 2005-06-05 09:21:37 UTC
Reopening to ...
Comment 11 Andrew Pinski 2005-06-05 09:21:54 UTC
Mark as a dup of bug 21920.

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