middle-end/9725: Invalid dependency determination

[Jan Beulich]

And even worse with bit fields: In

struct s {
	unsigned f1:16;
	unsigned f2:16;
};

void test(unsigned *pf, unsigned x, unsigned y) {
	unsigned f;

	((struct s*)&f)->f1 = x;
	((struct s*)&f)->f2 = y;
	*pf = f;
}

the structure, as I read the standard, qualifies for aliasing an
unsigned; the compiler doesn't honor this, however.
What I also don't understand is - why is the first store (here and in
all previous cases) not also being eliminated, not just the second, when
the compiler considers there is no aliasing possible between the
structure and the other type?

Looking even more forward to clarification of all of this; hopefully it
is just again so that I'm not seeing the full picture...

Thank you very much, Jan

>>> Momchil Velikov <velco@fadata.bg> 17.02.03 17:52:05 >>>
>>>>> "Jan" == Jan Beulich <JBeulich@novell.com> writes:

    Jan> I was fearing you would say this. But I can in no way agree -
the code
    Jan> presented is valid C, and hence should work at any
optimization level.

It is not valid C because it violates the following exceprt from the
ISO/IEC 9899:1999:

   [#7] An object shall have its stored value accessed only  by
       an lvalue expression that has one of the following types:73)

         -- a  type  compatible  with  the  effective  type  of the
            object,

         -- a qualified version  of  a  type  compatible  with  the
            effective type of the object,

         -- a   type   that   is   the   signed  or  unsigned  type
            corresponding to the effective type of the object,

         -- a  type  that  is   the   signed   or   unsigned   type
            corresponding  to  a qualified version of the effective
            type of the object,

         -- 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

         -- a character type.

~velco