"Segher Boessenkool" <segher@xxxxxxxxxxxxxxxxxxx> writes:
> With -fno-strict-aliasing, GCC is _also_ conformant. But in that
> case, it accepts programs that aren't conformant (in this aspect) and
> compiles them the way the user expects, at the cost of some missed
> optimisations.
Ok, are the examples given by the man page is an exhaustive list of no
conformant code accepted by Gcc with -fno-strict-aliasing switch ?
BTW, I tried to compile the last example, and we agreed that it invokes
undefined behaviour. I got no diagnostic when compiling it with "-Wall
-O2" switches. Is it expected ?
[...]
> -fstrict-aliasing is enabled at -O2 and up, yes. I don't understand
> what you find strange here?
Because when using -O0, that doesn't mean the aliasing rules should be
more relax and diagnostic should be removed.
>>>> AFAIK, this type of aliasing is defined by the standard.
>>>
>>> It is not. You're accessing an object of type "double" using
>>> an lvalue of type "int". This is not ok; see C99 6.5/7.
>>
>> Yes I think it's incorrect not because of aliasing issue, but because
>> of type punned stuff.
>
> Those issues are really the same thing. The only thing the standard
> specifies is what type lvalues you are allowed to use to access an
> object of given effective type (namely, that type (or qualified and/or
> signedness changed), or a union with a member of that type, or char).
You forgot structure I think.
Looking again at the second example:
int f() {
union a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
could you tell me what the effective type of 't.i' object ?
It sounds that you assume to be 'double'. If so could you tell how did
you get to this conclusion ?
>> And since the whole paragraph is about aliasing, I don't see the point
>> of this example.
>
> Some people mistakenly assume it will work. It does not. That's why
> the documentation warns about it.
>
>>>> Again in my understanding of the standard, this is an undefined
>>>> behaviour. So why does man page mention this case ?
>>>
>>> Because it is a common misunderstanding.
>>
>> Ok. So why not make it clear in the man page: "Note: since it's a common
>> mistake to think that the following code is correct, it's worth to
>> outline that it's not, and therefore Gcc assumes so."
>>
>> That would remove so much trouble to understand this paragraph.
>
> We could precede every statement in the manual with "the following might
> be useful to you:" :-)
>
> I don't find these paragraphs particularly confusing; maybe you can
> suggest a patch to make it even clearer though?
Well, looking at the different and wrong interpretations of strict
aliasing you can find on the Web, I don't think you're right.
And I don't think I'm the one who should make it clearer or not until I
know which undefined behaviours become defined with -fno-strict-aliasing.
Thanks
--
Francis
