[Bug fortran/125458] [13/14/15/16/17 Regression] Constant integer overflow not detected

[kargl at gcc dot gnu.org]

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.