https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125458
--- Comment #15 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- (In reply to kargls from comment #14) > On 6/28/26 12:32, tkoenig at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125458 > > > > --- Comment #12 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- > > (In reply to Steve Kargl from comment #11) > > > >> The finger points at Harald. > > > > That patch did not introduce the behavior, the regression is far older. > > Checking on godbolt, gfortran 7.1 has > > Yes, I know it has been pointed out that the regression > goes back beyond Harald's patch. Problem is that patch > now gets in the way as it changed several places to > try to make error handling consistent. If you hack > is_hard_arith_error() to return true, because an > overflow and -frange-check should produce an error, > one gets an ICE. The ICE occurs in an irrelevant code > path for your 3-line Fortran program. So, now one needs > to workaround a irrelevant code path to get to yet > another ICE. I've been down that path, and that is why I gave up (temporarily). I think that doing the checking entirely in resolution is likely to be the best path forward: a) we have to do it anyway to catch things like HUGE(1) + 1 b) Calling the same code twice with slightly different tasks is a bad idea. Especially freeing expressions is not needed during resolution, so we can remove that as a source of subsequent ICEs (and probably remove the hard_arith_error function as well) We might even be able to get rid of the rc handling and just issue errors directly, and get rid of things like seen_div0. But that would be a major cleanup. For a first fix (and something we could backport) removing the simplification during matching (and fixing fallout there) would be good. It will require a lot of test case tweaking, though...
