https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #12 from Jan Hubicka <hubicka at gcc dot gnu.org> --- Created attachment 47898 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47898&action=edit 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" 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.
