------- 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 <[EMAIL PROTECTED]> 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
