Clarification on Gcc's strict aliasing rules

[Francis Moreau]

"Segher Boessenkool" <segher@kernel.crashing.org> 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