[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered

["dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #21 from dberlin at gcc dot gnu dot org  2006-08-27 15:41 -------
Subject: Re:  [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered

> by noticing that if pt_anything is set, we indeed need to include all
> addressable vars in the clobbering:
>
This is also equivalent to marking every addressable variable as
clobbered whenever a function has any incoming pointers, as they will
point to anything, and escape.

I listed this as a conservatively correct solution in the email i sent
to mark (Mark everything clobbered).

> > So what do you think will happen when you add one level of indirection
> > to the mess, and TBAA now prunes out *that* alias instead, so you miss
> > it again? (IE break the chain of clobber transitivity one link in the
> > other direcftion).
>
> Do you have a testcase in mind?

Do you really want me to construct one?
Hopefully this will suffice:

Clobbering is a transitive property.

given
b = &e
a = b
c = a
d = c

a store to *d clobbers the values held by c, d, a, and b.
We will start with the solution that *d is clobbered, and attempt to
propagate it up the chain by following may-alias sets, till we mark e
as clobbered.  In this case, d, c, a, and b wll have e in their alias
set, so we only need to see the alias-set of any one of them to get
this correct.

However, if you add levels of indirection, like

b = &e
a = &b
c = &a
d = &c

The only way we will get to the fact that e can be clobbered is by
following the may-alias sets of each variable, d->c->a->b until we get
to something with e in the ma-yalias set.

If you add the right casts in, TBAA will prune the addresses from the
may-alias set of different variables, and you won't ever get all the
way to marking e clobbered.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778