Clarification on Gcc's strict aliasing rules

[Francis Moreau]

"Segher Boessenkool" <segher@kernel.crashing.org> writes:

>> I'm trying to understand what '-fstrict-aliasing' actually means.
>>
>> Looking at the man page, one can read:
>
>>
>>    -fstrict-aliasing
>>        Allow the compiler to assume the strictest aliasing
>>        rules applicable to the language being compiled.  For C
>>        [...]
>>
>> What does "the strictest aliasing rules ..." means ?
>
> It means the compiler is allowed to only guarantee behaviour that
> the relevant standards guarantee, treat undefined behaviour as
> undefined, etc.

Ok, then what's the point to have an option which make Gcc conformant ?

Is it because some programs out there don't care to be compliant and
want play trick with aliasings with -fno-strict-aliasing ?

That sounds weird since -fno-strict-aliasing seems to be enabled when no
optimisation levels have been passsed.

>> Also I don't really understand the examples provided by the man page. Ok
>> type punning using union is still allowed.
>
> It is allowed in C99, and a GCC extension for C90.  GCC guarantees
> behaviour for it always, also with -fstrict-aliasing.
>
>> But the second example which is:
>>
>>     However, this code might not:
>>
>> 		  int f() {
>> 		    union a_union t;
>> 		    int* ip;
>> 		    t.d = 3.0;
>> 		    ip = &t.i;
>> 		    return *ip;
>> 		  }
>>
>> _might_ not work. Why using 'might' ?
>
> It isn't guaranteed to work.  It can work by accident.  A lot
> of incorrect code sometimes works.
>
>> Does it work or not ?
>
> It isn't correct code.
>
>> 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.

And since the whole paragraph is about aliasing, I don't see the point
of this example.

Or maybe because type punning make this example incorrect then Gcc
assumes that this kind of alias is forbidden. But in that case
'strict-aliasing' means "remove some defined aliasing because even if
they are defined by the standard, they also can happen in a standard
defined way".

>
>> The third example is:
>>
>>     Similarly, access by taking the address, casting the
>>     resulting pointer and dereferencing the result has
>>     undefined behavior, even if the cast uses a union type,
>>     e.g.:
>>
>> 		  int f() {
>> 		    double d = 3.0;
>> 		    return ((union a_union *) &d)->i;
>> 		  }
>>
>> 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.

Thanks
-- 
Francis