This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Clarification on Gcc's strict aliasing rules
>> 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.
> 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 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).
>> -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.
>>> 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".
>>> 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?
> 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.
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? Would you be helped if there was an
example (or two) of the basic problem first?
Segher