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