This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: middle-end/9725: Invalid dependency determination
- From: "Jan Beulich" <JBeulich at novell dot com>
- To: <bangerth at dealii dot org>,<velco at fadata dot bg>
- Cc: <gcc-bugs at gcc dot gnu dot org>,<gcc-prs at gcc dot gnu dot org>, <nobody at gcc dot gnu dot org>
- Date: Wed, 19 Feb 2003 17:52:07 +0100
- Subject: Re: middle-end/9725: Invalid dependency determination
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 at fadata dot bg> 17.02.03 17:52:05 >>>
>>>>> "Jan" == Jan Beulich <JBeulich at novell dot 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