Re: Clarification on Gcc's strict aliasing rules

[Andrew Haley <aph at redhat dot com>]

On 11/08/2010 05:18 PM, Ian Lance Taylor wrote:
> Francis Moreau <francis.moro@gmail.com> writes:
> 
>> Ian Lance Taylor <iant@google.com> writes:
>>
>>> "Segher Boessenkool" <segher@kernel.crashing.org> writes:
>>>
>>>>> BTW, I tried to compile the last example, and we agreed that it invokes
>>>>> undefined behaviour.
>>>>
>>>> I did no such thing.  With -fno-strict-aliasing, the code is well-defined.
>>>
>>> I think I would say this slightly differently.  The code is still
>>> undefined according to the C/C++ language standards.  When you use
>>> -fno-strict-aliasing, gcc is promising to avoid using a class of
>>> optimizations based on those portions of the language standards.
>>> Another way to say this is that gcc is promising to not optimize based
>>> on the fact that memory locations are accessed using different types.
>>> That is, the code is still incorrect; gcc is just avoiding a class of
>>> optimizations which are known to cause trouble with real programs.
>>>
>>> I also am having trouble understanding what the OP is asking for here.
>>
>> Clarification on GCC's strict aliasing rules.
>>
>> But I think I got it now, although I still don't know which exactly
>> undefined behaviours are defined by GCC's -fno-strict-aliasing.
> 
> In the definitions that I use, I would say that no undefined behaviours
> are defined.
> 
> The -fno-strict-aliasing option disables a class of optimizations.
> These are optimizations which look at two pointer references and
> consider whether the two pointers might be pointing at the same memory
> location.  When -fno-strict-aliasing is in effect, these optimizations
> do not consider the types of the pointers.  When -fstrict-aliasing is in
> effect, these optimizations do consider the types of the pointers.
> 
> That's a moderately precise definition, but you'll note that it does not
> really describe the effects on the generated code, nor does it describe
> the types of source code that are supported.

I think it may be worth pointing out that we really don't want to define
a C-ish programming language of our own that defines a bunch of things
Standard C leaves undefined.  -fno-strict-aliasing is a concession to some
incorrect programs, that's all.

Andrew.