https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
kargl at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kargl at gcc dot gnu.org --- Comment #9 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #6) > It gets actually really weird during parsing. Nah. gfortran runs a sequence of matchers, and queues errors as it runs. If a matcher is not found, then (normally only) the last queued error message is emitted. If a matcher is found, the error message queue is cleaned up. > The following (invalid) code shows that the parser is still in an > early phase where it has not yet decided that it is a FORMAT statement, > but rather could be something else: > > format('x') = x > end > > This gives: > > 1 | format('x') = x > | 1 > Error: The function result on the lhs of the assignment at (1) must have the > pointer attribute. > > while e.g. Intel detects: > > foo.f90(1): error #6072: A dummy argument of a statement function must be a > scalar identifier. ['x'] > format('x') = x > ---------^ gfortran and ifort are simply trying different sequences of matchers. > The simplest solution is to defer error detection and recovery by restoring > the previous behavior when the basic type of operand 2 to gfc_divide is > non-numeric: > > diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c > index 1cd0867a941..dd72f44d377 100644 > --- a/gcc/fortran/arith.c > +++ b/gcc/fortran/arith.c > @@ -1828,7 +1828,8 @@ gfc_divide (gfc_expr *op1, gfc_expr *op2) > rc = ARITH_DIV0; > break; > default: > - gfc_internal_error ("gfc_divide(): Bad basic type"); > + /* basic type is non-numeric, handle this elsewhere. */ > + break; > } > if (rc == ARITH_DIV0) > { >From my long forgotten days of working in arith.c, it is almost always wrong to emit a gfc_internal_error. Typical an error message is generated during simplification or resolution that catches a problems.