[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000

--- Comment #15 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Sep 30, 2022 at 07:46:24PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #14 from anlauf at gcc dot gnu.org ---
> (In reply to Mikael Morin from comment #13)
> > If we pass this check, we proceed to reduce_binary, where if one (or both)
> > of the operands is an array, we do numerical evaluation for every element of
> > the array.
> > 
> > With the guarding check above, it is safe, with the assumption that elements
> > of an array have the same type as the array itself.  If that condition is
> > not true, well, it doesn't work obviously.
> > 
> > I don't see right now where an additional check would fit well, but the fix
> > doesn't belong to walk_array_constructor in any case from my point of view.
> 
> We could walk through the elements of each array passed to reduce_binary
> and check the types of the elements there, or do this check in a somewhat
> more clever way than in the patch attached to comment#3.
> 
> This patch tried to perform checks in reduce_binary_ac, but I was not happy
> with that particular implementation.
> 
> When looping over the elements, we currently have
> 
>       gfc_simplify_expr (c->expr, 0);
> 
>       if (c->expr->expr_type == EXPR_CONSTANT)
>         rc = eval (c->expr, op2, &r);
>       else
>         rc = reduce_binary_ac (eval, c->expr, op2, &r);
> 
> and do not handle the case that c->expr->ts.type == BT_UNKNOWN.
> Should we return sth. like rc = ARITH_INCOMMENSURATE, except that it is
> not array .op. array?
> 

walk_array_constructor was introduced when I added the typespec
to an array constructor, ie., [typespec :: xxx].  It was meant
to walk the constructor to do conversions if it could.   If
conversion could not be done, it was left for resolution stage.
It did not occur to me that someone might not write conforming
Fortran.  The purposed change to walk_array_constructor can
catch the simple cases.  Unfortuantely, if EXPR_OP leads to 
INTRINSIC_PARENTHESIS, there appears to be no way to easily
determine the type.  Harald's example of +(-(.true.)) is a
good example of the problem.