middle-end/9725: Invalid dependency determination

[Jan Beulich]

Indeed, I see. I that case (which I never was really aware of), it would
be very desirable for a compiler to emit a warning on the non-conforming
access rather than silently generating code that wasn't intended by the
programmer. I frequently see this sort of constructs used (not so much
using it myself since over time I came to avoid casts as much as
possible), and searching existing code for it will be a pain, though I
will have to do it to prevent further optimizer issues.

Thanks for pointing this out to me, and also thanks for considering
making the compiler emit a diagnostic for questionable casts to point at
cases where the optimizer may generate unintended code.

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