| Summary: | wrong-code with inlining and type-punned pointer | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Arne de Bruijn <gcc> |
| Component: | rtl-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | gcc-bugs |
| Priority: | P2 | ||
| Version: | 4.1.0 | ||
| Target Milestone: | --- | ||
| 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 | ||
|
Description
Arne de Bruijn
2005-05-05 15:35:23 UTC
Created attachment 8825 [details]
C source exposing problem
"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. (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. 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 (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. 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 (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) 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 (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)? Reopening to ... |