[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

["kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.