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.
