https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #12) > Created attachment 47898 [details] > possible fix > > After some discussion with Richard it is my understanding now that FRE is > considering two stores equal if they store same value, have same address and > the base+ref types matches. Because ref type is based on output on > component_uses_parent_alias_set_from which stops at unions (among others) it > will happily consider two stores equal even if their access paths are > completely different after first COMPONENT_REF to union possibly introducing > aliasing violations (at least in sense of C). > > This makes the access paths invalid for access path oracle as shown by > testcase in comment #5. > > The attached patch makes access path oracle to use same logic on terminating > the useful sequence of path. This causes three regressions: > > +FAIL: gcc.dg/tree-ssa/20030807-7.c scan-tree-dump-times vrp1 "if " 1 > +FAIL: gcc.dg/tree-ssa/alias-access-path-4.c scan-tree-dump-not optimized > "return 124" > +FAIL: gcc.dg/tree-ssa/alias-access-path-5.c scan-tree-dump-not optimized > "return 124" But that means we now miscompile the later two tests. > which all do accesses through unions which are disambiguable. > I will collect some data on this - it may be something for gcc 10 while we > may want to do something more sensible for next release. > > As discussed on IRC, adding to IRC check for access path equality is not > trivial because there may not be only one store to check.
