https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #28 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 > > alalaw01 at gcc dot gnu.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|INVALID |FIXED > > --- Comment #27 from alalaw01 at gcc dot gnu.org --- > (In reply to Richard Biener from comment #25) > > (In reply to alalaw01 from comment #23) > > > Well, this one is not fixed by -fno-aggressive-loop-optimizations. > > > > No, that just disabled one symptom of the issue at that point in time. > > Fixing the issue also fixes this occurance (well, I hope so ;)) > > So by "fixing the issue" - we mean, making --std=legacy prevent this (as > although against the SPEC, colleagues with more FORTRAN knowledge than I > suggest this is common)? SPEC seem to be saying they will not change the > source: https://www.spec.org/cpu2006/Docs/faq.html#Run.05 > > > As Jakub suggested in comment #13: > > > So, perhaps we want some flag on the Fortran COMMON decls that would be set > > on > COMMON that ends with an array and would tell get_ref_base_and_extent > > (and > > other spots?) that accesses can be beyond end of the decl? > > but only if --std=legacy ? ? ? > > Should I raise a new bug for this, as both this and 53068 are CLOSED? I think this has been discussed in some other dup already and the Fortran FE folks disagreed (it was never "legal", not even in F77). I also don't see how it can be a FE only fix. Possibly we can implemnet a middle-end switch that tells us that the size of commons is not to be trusted. The FE could then set that flag with -std=legacy. You can, after all, "simulate" the very same failure with C.