On Fri, 10 Nov 2006, Daniel Berlin wrote:
> > > It will load the value from memory, true, but who says that the store to
> > > memory will happen before that? The compiler is allowed to reorder the
> > > statements since it "knows" that foo and *arg cannot alias.
> > >
> >
> > If the compiler is smart enough to know how to reorder the statements,
> > then it should be smart enough to know that reordering will still leave
> > foo uninitialized, which is obviously an error.
>
> It's also undefined, so we can *and will* reorder things involving
> uninitialized variables.
> > Any time an
> > optimization/reordering visibly changes the results, that reordering is
> > broken.
> Not in this case.
> also Note that gcc *guarantees* the union trick will work, even though
> the standard does not.
>
> > And we already know that gcc is smart enough to recognize
> > attempts to use uninitialized variables, so there's no reason for it to
> > go there.
> We already do, particularly when it comes to constant propagation
>
> Relying on the idea that "oh, well, this is uninitialized, so the
> compiler can't touch it" is going to get you hurt one of these days :)
while speaking about uninitialized variables gcc developers probably want
to look at their own sources first:
gcc/testsuite/gcc.dg/vect/vect-27.c
int ia[N];
int ib[N+1];
for (i=0; i < N; i++)
{
ib[i] = i;
}
for (i = 1; i <= N; i++)
{
ia[i-1] = ib[i];
}
/* check results: */
for (i = 1; i <= N; i++)
{
if (ia[i-1] != ib[i])
abort ();
}
I hope that's not intentional, since higher optimizations in some compilers
break this incorrect code already.
Alex.
