GCC aliasing rules: more aggressive than C99?

[Richard Guenther]

On Wed, Jan 6, 2010 at 7:20 PM, Nick Stoughton <nick@msbit.com> wrote:
> On Sun, 2010-01-03 at 10:31 -0800, Patrick Horgan wrote:
>> Richard Guenther wrote:
>> > On Sun, Jan 3, 2010 at 6:46 AM, Joshua Haberman <jhaberman@gmail.com> wrote:
>> >
>> >> ... elision by patrick of part of a quote of 6.5 Expressions #7...
>> >>  * an aggregate or union type that includes one of the aforementioned
>> >>    types among its members (including, recursively, a member of a
>> >>    subaggregate or contained union), or
>> >>
>> >
>> > Literally interpreting this sentence the way you do removes nearly all
>> > advantages of type-based aliasing that you have when dealing with
>> > disambiguating a pointer dereference vs. an object reference
>> > and thus cannot be the desired interpretation (and thus we do not allow this).
>> >
>> Since it would be hard to read this any other way, it seems then you
>> maintain that you found a bug in the standard, has it been brought up to
>> the committee?  The latest draft I see still has that wording.  Doesn't
>> seem to be on the radar for C1x.  This same thing has bitten me, though
>> I agree with your rationale about how it would be a bad idea, still
>> strictly speaking, gcc is not standards compliant on this one point, and
>> rather than change gcc, the defect in the standard could be changed.  If
>> you don't have anyone participating on the committee right now, you only
>> have to convince some one who is, e.g. Nick Stoughton or P. J. Plauger
>> or Herb Sutter, right?
>
> Herb is C++ ...
>
> The C1x timetable has us finishing the draft for an initial ballot this
> summer (the April Florence meeting being the last chance to submit new
> material). The best expert I know on the type based aliasing stuff is
> Clark Nelson at Intel (clark.nelson@intel.com). We did spend a
> considerable amount of time at the recent Santa Cruz meeting discussing
> this subject ... see N1409 and N1422 (the minutes including a summary of
> the discussion on N1409).
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf

The case we are discussing here doesn't seem to be covered in that.
Let's modify Example 2 in 4.16 of n1422 to

struct S { int a; };
int i;
int f2 (struct S *ps, struct S s)
{
  *ps = s;
  return i;
}

can the compiler assume that i is not modified through the ps[i] lvalue?
Thus, is calling the above as

f2 ((struct S *)&pi, (struct S){ 1 });

valid?  6.5/7 point 5 may suggest that it is indeed valid, because
the lvalue is of type struct S which is an aggregate type and it
includes int as member which is a type compatible with the
effective type of the object.

What about the slightly different variant

struct S { int a; int b; };
int i;
int f2 (struct S *ps, struct S s)
{
  ps->a = s.a;
  return i;
}

GCC will in both cases assume that the store cannot alias i.

I have no idea on how to raise this issue with the std body, somebody
else might and can pass on the above example please.

Thanks,
Richard.