https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125458
--- Comment #16 from Steve Kargl <kargl at gcc dot gnu.org> --- (In reply to Thomas Koenig from comment #15) > (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 Yes, a function reference needs to go through resolution. There may be a few special cases for inquiry functions that are done during matching, but I haven't tried to locate one. OTOH, program main integer :: x = 2_8**30 + 2**30 integer :: y = 2**30 + 2**30 print *, x end program main issues an overflow error for x with or without -frange-check during matching. y is simply compiled and wraps around. -frange-check has not effect on y. > 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) I agree. A slightly less quick glance at arith.cc shows ample opportunity of cleanup, e.g., static arith gfc_arith_gt (gfc_expr *op1, gfc_expr *op2, gfc_expr **resultp) { gfc_expr *result; if (op1->ts.type != op2->ts.type) return ARITH_INVALID_TYPE; /* Irrelevant code removed.*/ return ARITH_OK; } I have been unable to construct an example that triggers the 'if (...)' type check. > 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... Yes, it will be a major cleanup, if not, code rewrite. Many of the functions in arith.cc have a 'arith' return type and the returned value signals success or not. These functions are referenced via pointers passed into other functions. BTW, I suspect you know your program is nonconforming, so technically gfortran can do anything.
