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
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
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
