Re: [PATCH, v2] Fortran: handle bad array ctors with typespec [PR93483, , PR107216, PR107219]

[Harald Anlauf <anlauf@gmx.de>]

Hi Mikael,

Am 16.10.22 um 23:17 schrieb Mikael Morin:
> Le 15/10/2022 à 22:15, Harald Anlauf via Fortran a écrit :
>> Dear all,
>>
>> here is an updated version of the patch that includes suggestions
>> and comments by Mikael in PR93483.
>>
>> Basic new features are:
>> - a new enum value ARITH_NOT_REDUCED to keep track if we encountered
>>    an expression that was not reduced via reduce_unary/reduce_binary
>> - a cleanup of the related checking, resulting in more readable
>>    code.
>> - a new testcase by Mikael that exhibited a flaw in the first patch
>>    due to a false resolution of a symbol by premature simplification.
>>
>> Regtested again.  OK for mainline?
>>
> (...)
>> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
>> index 10bb098d136..7b8f0b148bd 100644
>> --- a/gcc/fortran/gfortran.h
>> +++ b/gcc/fortran/gfortran.h
>> @@ -222,11 +222,12 @@ enum gfc_intrinsic_op
>>     Assumptions are made about the numbering of the interface_op
>> enums.  */
>>  #define GFC_INTRINSIC_OPS GFC_INTRINSIC_END
>>
>> -/* Arithmetic results.  */
>> +/* Arithmetic results.  ARITH_NOT_REDUCED is used to keep track of
>> failed
>> +   reductions because an erroneous expression was encountered.  */
>
> The expressions are not always erroneous.  They can be, but in the
> testcase for example, all the expressions are valid.  They are just
> unsupported by the arithmetic evaluation code which works only with
> literal constants and arrays of literal constants (and arrays of arrays
> etc).
>
> OK with that comment fixed.

you're absolutely right.  I adjusted the comment and the commit
message according to your suggestion.

Pushed as https://gcc.gnu.org/g:d45af5c2eb1ba1e48449d8f3c5b4e3994a956f92

Thanks,
Harald

> Thanks.
>