https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #53 from alalaw01 at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #44) > I don't have access to SPEC, so I can only guess... Is there maybe an > equivalence involved, something like Turns out the COMMON is accessed via a MEM_REF in a loop, or as a VAR_DECL inside. Go figure! :) (In reply to Dominique d'Humieres from comment #49) > I don't see the point to add yet another option just because "SPEC does not > want to change the invalid Fortran". I think SPEC should be run with the > option(s) causing the problem disabled. Anecdotally I hear from Fortran-using colleagues this may occur in other places too. Moreover, the list of phases using get_ref_base_and_extent, is long; we could end up compiling with an ever-growing -fno-this -fno-that as more and more phases make use of the "bad" analysis results (that is correct by the language spec after all). In this case, there are a few other equivalences found due to the tree-ssa-scopedtables.c changes, that we'd lose with -fno-tree-dominator-opts, too. (In reply to H.J. Lu from comment #52) > >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid? Not everyone wants to patch SPEC sources.
