Re: Clarification on Gcc's strict aliasing rules

[Francis Moreau <francis dot moro at gmail dot com>]

"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 ?
>
> It is not an exhaustive list.
>

I think seeing a precise list of undefined behaviours that becomes
defined with -fno-strict-aliasing should be given so users know just
what to expect.

>
>> 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 we did but with the standard view.

>> I got no diagnostic when compiling it with "-Wall
>> -O2" switches. Is it expected ?
>
> Yes.  -O0 implies -fno-strict-aliasing.  -Wstrict-aliasing requires
> -fstrict-aliasing to do anything (unfortunate that, but that's the
> way it is).
>

Ok, you responded in another post.

>
>>> -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.
>
> What do you mean here?  Are you saying you would like GCC to be improved?
> We all want that.  Or are you saying GCC's behaviour is incorrect?  We'll
> have to disagree on that.
>

I mean that I find quite dangerous that a program can subtly break (or
behave differently) depending on the optimisation level.

For example a user can rely on aliasing undefined behaviour (one reason
is that is simply not aware of this fact), compile its program with no
optimisation level, do some testings and find no problem so far. Then
increase the level of optimisation and then the program start to behave
incorrectly. I guess he's going to spend some time before discovering
what's going on.

Specially since no warnings can pop up with -O2 for example.

>>>> 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 ?
>
> int, if you can say that object exists at all: it does not have a stored
> value.  The stored value of t is a double with value 3.0 .  You can
> take its address and access it via that as "double" (or "char"), or you
> can access it as the union it is.  You can not access it as "int".
>

Ok.

>
>>>> 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 you're saying all that misunderstanding is there because of a few
> lines in the GCC manual that are there to try to reduce the existing
> misunderstanding?

No, the misunderstanding is not coming from the GCC manual.

Aliasing is a pretty hard part to decipher from the C standard.

But I don't think GCC manual helps to clarify this point even worse I
think it obfuscates the picture, IMHO.

>> 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.
>
> You are the one who has problems with these paragraphs in the documentation,
> so we need your input on what is unclear.

Sure, if I can help.

> I think the core problem here is that the manual spends a few lines on the
> basic stuff, and then spends a lot more lines touching on some of the
> finer points; people who do not fully understand the subject yet confuse
> the one for the other.  And those people are extra likely to look at this
> documentation!
>
> Is that your impression as well?

Yes mostly, but the wording sounds (for my not native english speaker
ears) clear as it could.

For example starting the paragraph like this:

   -fstrict-aliasing

       For C, the standard defines a set of rules where aliasing can
       happen. With this option, GCC strictly uses them leaving the
       undefined behaviours cases (an exhaustive list is given below)
       still undefined for the sake of optimisations.

       However some real (no conforming) programs rely on these
       undefined behaviours. Therefore passing -fno-strict-aliasing make
       them work as expected by avoiding a class of optimisations.

       < list of undefined behaviours>

> Would you be helped if there was an example (or two) of the basic
> problem first?

An exhaustive list would be better I think.

-- 
Francis