[Bug tree-optimization/29156] [4.2 Regression] Misscompilation with structs due to new struct alias

dberlin at dberlin dot org gcc-bugzilla@gcc.gnu.org
Thu Sep 21 12:15:00 GMT 2006



------- Comment #5 from dberlin at gcc dot gnu dot org  2006-09-21 12:15 -------
Subject: Re:  [4.2 Regression] Misscompilation with structs due to new struct
alias

On 21 Sep 2006 04:23:24 -0000, pinskia at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #4 from pinskia at gcc dot gnu dot org  2006-09-21 04:23 -------
> may_alias_p returns true
> for:
> (gdb) p debug_generic_expr (ptr)
> xaD.1527
> (gdb) p debug_generic_expr (var)
> SMT.5D.1548
>
>
> (In reply to comment #2)
> > So, actually, i'm pretty sure they should have the same SMT, because they
> > should be in the same alias set.
> They are not the exact same aliasing set but conflicting ones.

actually, they aren't just conflicting, one is a complete subset of another.

> > Why do they get different SMT's?
> Because of this:
>   /* To avoid creating unnecessary memory tags, only create one memory tag
>      per alias set class.  Note that it may be tempting to group
>      memory tags based on conflicting alias sets instead of
>      equivalence.
>  That would be wrong because alias sets are not
>      necessarily transitive (as demonstrated by the libstdc++ test
>      23_containers/vector/cons/4.cc).  Given three alias sets A, B, C
>      such that conflicts (A, B) == true and conflicts (A, C) == true,
>      it does not necessarily follow that conflicts (B, C) == true.  */

Yeah, but then you run into the situation we have here where there are
no "real" variables to hold these two sets together.  In other words,
this won't work if you have no addressable variables in your function
that could conflict with both.

Diego, pruning isn't doing anything wrong here.
One thing that would work properly is to create fake non-local
variables for each parameter's pointed to type.  Then one of the SMT's
will end up with both parameter symbols in it's alias sets, and
everything will work.
Otherwise, there are no addressable variables that will cause these
two sets to be believed to be the same.

I will implement this solution.


-- 


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



More information about the Gcc-bugs mailing list