Re: [PATCH] Fortran: error recovery on invalid array reference of non-array [PR103590]

[Harald Anlauf <anlauf@gmx.de>]

Hi Mikael,

Am 19.07.22 um 11:03 schrieb Mikael Morin:
> Hello,
> 
> the principle looks good, but...
> 
> Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit :
> 
>> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
>> index 2ebf076f730..dacd33561d0 100644
>> --- a/gcc/fortran/resolve.cc
>> +++ b/gcc/fortran/resolve.cc
>> @@ -5004,7 +5004,11 @@ find_array_spec (gfc_expr *e)
>>        {
>>        case REF_ARRAY:
>>      if (as == NULL)
>> -      gfc_internal_error ("find_array_spec(): Missing spec");
>> +      {
>> +        gfc_error ("Symbol %qs at %L has not been declared as an array",
>> +               e->symtree->n.sym->name, &e->where);
> 
> ... the error here only makes sense if the array reference follows a 
> variable reference.  If it follows a derived type component reference, a 
> slightly different error message would be more appropriate.

how detailed or tailored should the error message be, or can
we just have a more generic message, like "Name at %L ...",
or "Invalid subscript reference at %L"?  We seem to not hit
that internal error very often...

I have played only little with invalid code in the present context,
but often hit another code path that shows up in associate_54.f90
and gives

Error: Associate-name 'state' at (1) is used as array

For the testcase in the PR, Intel says:

associate_59.f90(7): error #6410: This name has not been declared as an 
array or a function.   [A]
     print *, [character(a(1)) :: '1'] ! { dg-error "Scalar INTEGER 
expression" }
------------------------^

Crayftn 14.0 says:

   Improper ir tree in expr_semantics.

     print *, [character(a(1)) :: '1'] ! { dg-error "Scalar INTEGER 
expression" }
                          ^ 

ftn-873 crayftn: ERROR P, File = associate_59.f90, Line = 7, Column = 26
   Invalid subscripted reference of a scalar ASSOCIATE name.


gfortran's behavior during error handling is difficult to understand.
While the proposed new error message is emitted for associate_54.f90,
it never makes it far enough for the testcase of the present PR
(associate_59.f90).

Thanks,
Harald