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

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

------- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz  2006-09-21 12:22 -------
Subject: Re:  [4.2 Regression] Misscompilation with structs due to  new struct
alias

> > > 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.

it is probably not enough to consider just types of the parameters.
I wrote the testcase this way since it is simpler, but it should fail
exactly the same way with

struct test1 *out_of_nowhere_1 (void);
struct test2 *out_of_nowhere_2 (void);

int bla(void)
{
  struct test1 *xa = out_of_nowhere_1 ();
  struct test2 *xb = out_of_nowhere_2 ();
  global = 1;
  xb->sub.a = 1;
  xa->a = 8;
  return xb->sub.a;
}


-- 


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