Re: [PATCH, v2] Fortran: error recovery for invalid types in array constructors [PR107000]

[Mikael Morin <morin-mikael@orange.fr>]

Le 06/10/2022 à 23:36, Harald Anlauf a écrit :
>>
>> For example, for this case:
>>
>> [real :: 2] * [real :: +(.true.)]
>>
>> First there is a "root" invocation of reduce binary with arguments [real
>> :: 2] and [real :: +(.true.)]
>> The root invocation of reduce_binary will call reduce_binary_aa. This is
>> normal.
>>
>> Then reduce_binary_aa calls reduce_binary again with arguments 2 and
>> +(.true.).  And reduce_binary calls again reduce_binary_aa with those
>> arguments.  This is weird, reduce_binary_aa is supposed to have arrays
>> for both arguments.
> 
> Am I seeing something different from you?  My gdb says
> that one argument of reduce_binary is EXPR_CONSTANT,
> the other EXPR_OP and BT_UNKNOWN.  Both rank 0.
> 
No, I get the same, and the program goes to reduce_binary_aa with those 
arguments; this is the problem.

>> The same goes for the array vs constant case, reduce_binary_ca (or
>> reduce_binary_ac) is invoked with two scalars, while if you look at
>> reduce_binary, you would expect that we only get to reduce_binary_ca
>> with a scalar constant and an array as arguments.
>>
>>
>> I think the checks in the three reduce_binary_* functions should be
>> moved into their respective loops, so that we detect the invalid type
>> just before these weird recursive calls instead of just after entering
>> into them.
> 
> I think I tried that before, and it didn't work.
> There was always one weird case that lead to a bad or
> invalid constructor for one of the arrays you want to
> look at in the respective loop,  and this is why the
> testcase tries to cover everything that I hit then and
> there... (hopefully).  So I ended up with the check
> before the loop.
> 
I see, I'll have a look.

> What do we actually gain with your suggested change?
> Moving the check into the loop does not really make
> the code more readable to me.  And the recursion is
> needed anyway.
> 
I think we gain clarity, consistency.

I try to rephrase again.
 From a high level point of view, to evaluate a binary operator you need 
a specific (one for each operator) function to evaluate the scalar vs 
scalar case, and three generic (they are common to all the operators) 
functions to handle respectively:
  - the scalar vs array case,
  - the array vs scalar case,
  - the array vs array case,
by calling in a loop the scalar specific function.
Here we are only dealing with constants, arrays of constants, arrays of 
arrays, etc, all valid cases.

Your patch introduces support for invalid cases, that is invalid values 
that can't be reduced to a constant.  This is fine, and it works.
What is weird is that the scalar vs invalid scalar case is caught in the 
array vs array function.