[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
--- 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
--- 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
[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
--- 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
schlie at comcast dot net [EMAIL PROTECTED] 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
--- 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 [EMAIL PROTECTED] 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
--- 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
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
--- 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
--- 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
--- 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=8825action=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
--- 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
--- 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
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
--- 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
