https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125458
--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #4)
> (In reply to Thomas Koenig from comment #3)
> > OK.
> >
> > There is also no error for this test case:
> >
> > print *,1e20 * 1e20
> > end
> >
> > A gfc_error is issued, but it is later rejected because the
> > match is succesful.
> >
> Is it? A statement pattern successfully matched with an error should be an
> error, not a successful match.
Part of a debugging session for the integer test case:
Breakpoint 1, gfc_arith_times (op1=0x3cec310, op2=0x3cec510,
resultp=0x7fffffffcf98) at ../../dump/gcc/fortran/arith.cc:836
836 if (op1->ts.type != op2->ts.type)
(gdb) n
839 result = gfc_get_constant_expr (op1->ts.type, op1->ts.kind,
&op1->where);
(gdb) n
841 switch (op1->ts.type)
(gdb) n
844 mpz_mul (result->value.integer, op1->value.integer,
op2->value.integer);
(gdb) fin
Run till exit from #0 gfc_arith_times (op1=0x3cec310, op2=0x3cec510,
resultp=0x7fffffffcf98) at ../../dump/gcc/fortran/arith.cc:844
0x0000000000ab450b in eval_intrinsic (op=op@entry=INTRINSIC_TIMES,
eval=eval@entry=..., op1=0x3cec310, op2=0x3cec510)
at ../../dump/gcc/fortran/arith.cc:1962
1962 rc = reduce_binary (eval.f3, op1, op2, &result);
Value returned is $1 = ARITH_OVERFLOW
(gdb) fin
Run till exit from #0 0x0000000000ab450b in eval_intrinsic
(op=op@entry=INTRINSIC_TIMES, eval=eval@entry=..., op1=0x3cec310,
op2=0x3cec510)
at ../../dump/gcc/fortran/arith.cc:1962
match_add_operand (result=result@entry=0x7fffffffd128) at
../../dump/gcc/fortran/matchexp.cc:452
452 if (total == NULL)
Value returned is $2 = (gfc_expr *) 0x3cec600
(gdb) p total
$3 = (gfc_expr *) 0x3cec600
(gdb) call debug(total)
28958985279684 (INTEGER 4)
(which is bogus), but then...
(gdb) fin
Run till exit from #0 match_add_operand (result=result@entry=0x7fffffffd128)
at ../../dump/gcc/fortran/matchexp.cc:452
match_level_2 (result=result@entry=0x7fffffffd180) at
../../dump/gcc/fortran/matchexp.cc:538
538 if (m != MATCH_YES)
Value returned is $4 = MATCH_YES
so match_add_operand returns MATCH_YES, and the gfc_error is ignored.
>
> > print *,2*huge(1.0)
> >
> > goes through resolution, where we issue the error.
> >
> Why doesn't it happen in the other case?
The evaluation of HUGE(1.0) is delayed until resolution.
> > It would be possible to remove the arithmetic simplification
> > from matching, or just re-check on resolution.
> >
> ... or really reject on matching (but I'm afraid of side-effects).
Jep. I tried that (by adjusting is_hard_arith_error to return
flag-dependent values, but that got a few ICE). The logic there
is rather twisted.
The fortran-original dump is amusing, BTW:
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = main
symtree: 'main' || symbol: 'main'
type spec : (UNKNOWN 0)
attributes: (PROGRAM PUBLIC SUBROUTINE IS-MAIN-PROGRAM)
code:
WRITE UNIT=6 FMT=-1
TRANSFER 28958985279684
DT_END
