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

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

[gscfq@t-online.de]

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

            Bug ID: 107000
           Summary: ICE in gfc_real2complex, at fortran/arith.cc:2243
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   complex :: x(1)
   x = (1.0, 2.0) * [real :: +'1']
   x = (1.0, 2.0) * [real :: -'1']
end


$ cat z2.f90
program p
   complex :: x
   x = (1.0, 2.0) * [real :: +'1']
   x = (1.0, 2.0) * [real :: -'1']
end


$ gfortran-13-20220918 -c z1.f90
f951: internal compiler error: Segmentation fault
0xf3a72f crash_signal
        ../../gcc/toplev.cc:314
0x7be3a1 gfc_real2complex(gfc_expr*, int)
        ../../gcc/fortran/arith.cc:2243
0x890cb2 gfc_convert_constant(gfc_expr*, bt, int)
        ../../gcc/fortran/simplify.cc:8754
0x808edb do_simplify
        ../../gcc/fortran/intrinsic.cc:4658
0x814a51 gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int, bool)
        ../../gcc/fortran/intrinsic.cc:5384
0x7bb887 eval_intrinsic
        ../../gcc/fortran/arith.cc:1591
0x82e2bc match_add_operand
        ../../gcc/fortran/matchexp.cc:392
0x82e46c match_level_2
        ../../gcc/fortran/matchexp.cc:480
0x82e5c2 match_level_3
        ../../gcc/fortran/matchexp.cc:551
0x82e6b4 match_level_4
        ../../gcc/fortran/matchexp.cc:599
0x82e6b4 match_and_operand
        ../../gcc/fortran/matchexp.cc:693
0x82e8a2 match_or_operand
        ../../gcc/fortran/matchexp.cc:722
0x82e972 match_equiv_operand
        ../../gcc/fortran/matchexp.cc:765
0x82ea44 match_level_5
        ../../gcc/fortran/matchexp.cc:811
0x82de11 gfc_match_expr(gfc_expr**)
        ../../gcc/fortran/matchexp.cc:870
0x825450 gfc_match(char const*, ...)
        ../../gcc/fortran/match.cc:1131
0x8271e9 gfc_match_assignment()
        ../../gcc/fortran/match.cc:1330
0x851950 match_word
        ../../gcc/fortran/parse.cc:67
0x851950 decode_statement
        ../../gcc/fortran/parse.cc:363
0x85344a next_free
        ../../gcc/fortran/parse.cc:1399

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

[gscfq@t-online.de]

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

G. Steinmetz <gscfq@t-online.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code

--- Comment #1 from G. Steinmetz <gscfq@t-online.de> ---

Some more variants :


$ cat zz1.f90
program p
   complex :: x(1)
   real :: y
   x = (1.0, 2.0) * [complex :: +'1']
   x = (1.0, 2.0) * [complex :: -'1']
   y = 2 * [complex :: +'1']
   y = 2 * [complex :: -'1']
   y = 2 * [real :: +'1']
   y = 2 * [real :: -'1']
end


$ cat zz2.f90
program p
   complex :: x
   real :: y(1)
   x = (1.0, 2.0) * [complex :: +'1']
   x = (1.0, 2.0) * [complex :: -'1']
   y = 2 * [complex :: +'1']
   y = 2 * [complex :: -'1']
   y = 2 * [real :: +'1']
   y = 2 * [real :: -'1']
end

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-09-21

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.

Comment#0 is fixed by e.g.

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index d57059a375f..1f290050189 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -2238,6 +2238,9 @@ gfc_real2complex (gfc_expr *src, int kind)
   arith rc;
   bool did_warn = false;

+  if (src->ts.type != BT_REAL)
+    return NULL;
+
   result = gfc_get_constant_expr (BT_COMPLEX, kind, &src->where);

   mpc_set_fr (result->value.complex, src->value.real, GFC_MPC_RND_MODE);


but comment#1 has a different stack trace, as it hits an assert.

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

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 53601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53601&action=edit
Hackish patch

This patch fixes all ICE in comment#0 and comment#1.
However, it papers over the issue that we forget about
earlier errors: while

  print *,     [real :: -'1']

is diagnosed for the invalid unary "-",

  print *, 2 * [real :: -'1']

will throw a different error.
So I'm not really happy with the hack.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> Created attachment 53601 [details]
> Hackish patch
> 
> This patch fixes all ICE in comment#0 and comment#1.
> However, it papers over the issue that we forget about
> earlier errors: while
> 
>   print *,     [real :: -'1']
> 
> is diagnosed for the invalid unary "-",
> 
>   print *, 2 * [real :: -'1']
> 
> will throw a different error.
> So I'm not really happy with the hack.

I think we need to expand the checking in array.cc

  /* Convert components of an array constructor to the type in ts.  */

  static match
  walk_array_constructor (gfc_typespec *ts, gfc_constructor_base head)

I haven't had time to look deeper, but this function should be comparing
the typespecs of REAL and -'1' or +'1'.  That should fail.  I suspect that
the EXPR_OP of type_expr is allowing the array constructor walk to succeed.

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

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> I think we need to expand the checking in array.cc
> 
>   /* Convert components of an array constructor to the type in ts.  */
> 
>   static match
>   walk_array_constructor (gfc_typespec *ts, gfc_constructor_base head)
> 
> I haven't had time to look deeper, but this function should be comparing
> the typespecs of REAL and -'1' or +'1'.  That should fail.  I suspect that
> the EXPR_OP of type_expr is allowing the array constructor walk to succeed.

You mean sth. like:

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..78a15917cec 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1213,7 +1213,7 @@ walk_array_constructor (gfc_typespec *ts,
gfc_constructor_base head)
            return m;
        }
       else if (!gfc_convert_type_warn (e, ts, 1, 1, true)
-              && e->ts.type != BT_UNKNOWN)
+              && (e->ts.type != BT_UNKNOWN || e->expr_type == EXPR_OP))
        return MATCH_ERROR;
     }
   return MATCH_YES;

in addition to the fix from comment#2?  This works and regtests ok.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Sep 26, 2022 at 08:38:56PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #4)
> > I think we need to expand the checking in array.cc
> > 
> >   /* Convert components of an array constructor to the type in ts.  */
> > 
> >   static match
> >   walk_array_constructor (gfc_typespec *ts, gfc_constructor_base head)
> > 
> > I haven't had time to look deeper, but this function should be comparing
> > the typespecs of REAL and -'1' or +'1'.  That should fail.  I suspect that
> > the EXPR_OP of type_expr is allowing the array constructor walk to succeed.
> 
> You mean sth. like:
> 
> diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
> index bbdb5b392fc..78a15917cec 100644
> --- a/gcc/fortran/array.cc
> +++ b/gcc/fortran/array.cc
> @@ -1213,7 +1213,7 @@ walk_array_constructor (gfc_typespec *ts,
> gfc_constructor_base head)
>             return m;
>         }
>        else if (!gfc_convert_type_warn (e, ts, 1, 1, true)
> -              && e->ts.type != BT_UNKNOWN)
> +              && (e->ts.type != BT_UNKNOWN || e->expr_type == EXPR_OP))
>         return MATCH_ERROR;
>      }
>    return MATCH_YES;
> 
> in addition to the fix from comment#2?  This works and regtests ok.
> 

Yes, that would work!  I was thinking of something more complex
such as looking at the types of the operand(s), but simplification
probably handles +1 and -1 correctly and punts on +'1' and -'1'.

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

[anlauf at gcc dot gnu.org]

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #6)
> Yes, that would work!  I was thinking of something more complex
> such as looking at the types of the operand(s), but simplification
> probably handles +1 and -1 correctly and punts on +'1' and -'1'.

I played some more and found that we would regress on e.g.

  print *, [real :: 1, +real(2.0)]

while

  print *, [real :: 1,  real(2.0)]

is fine.

So we need a better solution...

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

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> (In reply to Steve Kargl from comment #6)
> > Yes, that would work!  I was thinking of something more complex
> > such as looking at the types of the operand(s), but simplification
> > probably handles +1 and -1 correctly and punts on +'1' and -'1'.
> 
> I played some more and found that we would regress on e.g.
> 
>   print *, [real :: 1, +real(2.0)]
> 
> while
> 
>   print *, [real :: 1,  real(2.0)]
> 
> is fine.
> 
> So we need a better solution...

This is the type of solution I had in mind.  It allows the above
and catches +.false. and -.true.

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..8b689f28612 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1205,6 +1205,21 @@ walk_array_constructor (gfc_typespec *ts,
gfc_constructor_base head)
   for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
     {
       e = c->expr;
+
+      /* Special case unary operators to catch [real :: +'1'].  */
+      if (e->expr_type == EXPR_OP && e->ts.type == BT_UNKNOWN)
+       {
+         gfc_expr *op1 = e->value.op.op1;
+         if ((op1->value.op.op == INTRINSIC_UMINUS
+              || op1->value.op.op == INTRINSIC_UPLUS)
+             && !gfc_numeric_ts (&op1->ts))
+           {
+             gfc_error("Invalid operand of unary operator at %L",
+                       &op1->where);
+             return MATCH_ERROR;
+           }
+       }
+
       if (e->expr_type == EXPR_ARRAY && e->ts.type == BT_UNKNOWN
          && !e->ref && e->value.constructor)
        {

Unfortunately, it ICEs with 

 print *, [real :: 1, +(.true)]

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

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #8)
> (In reply to anlauf from comment #7)
> > (In reply to Steve Kargl from comment #6)
> > > Yes, that would work!  I was thinking of something more complex
> > > such as looking at the types of the operand(s), but simplification
> > > probably handles +1 and -1 correctly and punts on +'1' and -'1'.
> > 
> > I played some more and found that we would regress on e.g.
> > 
> >   print *, [real :: 1, +real(2.0)]
> > 
> > while
> > 
> >   print *, [real :: 1,  real(2.0)]
> > 
> > is fine.
> > 
> > So we need a better solution...
> 
> This is the type of solution I had in mind.  It allows the above
> and catches +.false. and -.true.
> 
> diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
> index bbdb5b392fc..8b689f28612 100644
> --- a/gcc/fortran/array.cc
> +++ b/gcc/fortran/array.cc
> @@ -1205,6 +1205,21 @@ walk_array_constructor (gfc_typespec *ts,
> gfc_constructor_base head)
>    for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
>      {
>        e = c->expr;
> +
> +      /* Special case unary operators to catch [real :: +'1'].  */
> +      if (e->expr_type == EXPR_OP && e->ts.type == BT_UNKNOWN)
> +	{
> +	  gfc_expr *op1 = e->value.op.op1;
> +	  if ((op1->value.op.op == INTRINSIC_UMINUS
> +	       || op1->value.op.op == INTRINSIC_UPLUS)
> +	      && !gfc_numeric_ts (&op1->ts))
> +	    {
> +	      gfc_error("Invalid operand of unary operator at %L",
> +			&op1->where);
> +	      return MATCH_ERROR;
> +	    }
> +	}
> +
>        if (e->expr_type == EXPR_ARRAY && e->ts.type == BT_UNKNOWN
>  	  && !e->ref && e->value.constructor)
>  	{
> 
> Unfortunately, it ICEs with 
> 
>  print *, [real :: 1, +(.true)]


This catches the parenthesis.

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..21027844f84 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1205,6 +1205,24 @@ walk_array_constructor (gfc_typespec *ts,
gfc_constructor_base head)
   for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
     {
       e = c->expr;
+
+      /* Special case unary operators to catch [real :: +'1'].  */
+      if (e->expr_type == EXPR_OP && e->ts.type == BT_UNKNOWN)
+       {
+         gfc_expr *op1 = e->value.op.op1;
+         if ((op1->value.op.op == INTRINSIC_UMINUS
+               || op1->value.op.op == INTRINSIC_UPLUS
+               || (op1->expr_type == EXPR_OP
+                   && op1->value.op.op == INTRINSIC_PARENTHESES))
+             && (op1->ts.type == BT_CHARACTER
+                 || op1->ts.type == BT_LOGICAL))
+           {
+             gfc_error("Invalid operand of unary operator at %L",
+                       &op1->where);
+             return MATCH_ERROR;
+           }
+       }
+
       if (e->expr_type == EXPR_ARRAY && e->ts.type == BT_UNKNOWN
          && !e->ref && e->value.constructor)
        {

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

[anlauf at gcc dot gnu.org]

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #9)
> This catches the parenthesis.

... but it is still not sufficient to handle ugly stuff like:

  print *, [real :: 1, +(+(.true.))] * 2

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Sep 29, 2022 at 07:57:24PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #9)
> > This catches the parenthesis.
> 
> ... but it is still not sufficient to handle ugly stuff like:
> 
>   print *, [real :: 1, +(+(.true.))] * 2
> 

Hmmm, there is gfc_resolve_expr().  I don't know if it
is too early in the parsing to use it.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Sep 29, 2022 at 08:10:14PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
> On Thu, Sep 29, 2022 at 07:57:24PM +0000, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> > 
> > --- Comment #10 from anlauf at gcc dot gnu.org ---
> > (In reply to kargl from comment #9)
> > > This catches the parenthesis.
> > 
> > ... but it is still not sufficient to handle ugly stuff like:
> > 
> >   print *, [real :: 1, +(+(.true.))] * 2
> > 
> 
> Hmmm, there is gfc_resolve_expr().  I don't know if it
> is too early in the parsing to use it.

gfc_resolve_expr() does not help. :(

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

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> ---
Here is my understanding of the problem.

There is a check on operand types in eval_intrinsic guarding numerical
evaluation:

1573    case INTRINSIC_PLUS:
1574    case INTRINSIC_MINUS:
1575    case INTRINSIC_TIMES:
1576    case INTRINSIC_DIVIDE:
1577    case INTRINSIC_POWER:
1578      if (!gfc_numeric_ts (&op1->ts) || !gfc_numeric_ts (&op2->ts))
1579    goto runtime;

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.

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

[anlauf at gcc dot gnu.org]

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?

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

[sgk at troutmask dot apl.washington.edu]

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.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53601|0                           |1
        is obsolete|                            |

--- Comment #16 from anlauf at gcc dot gnu.org ---
Created attachment 53651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53651&action=edit
Revised patch

This variant adds a check after the place Mikael pointed out, and
which verifies that the types of all elements of an array ctor
are the same.  Testing so far indicates that it is robust enough
for all cases discussed in this PR, although it mostly emits

Error: Cannot convert UNKNOWN to ...

for every expression involving a binary operator.

Is this going into the right direction?

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

[anlauf at gcc dot gnu.org]

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #16)
> Created attachment 53651 [details]
> Revised patch

Unfortunately this regresses on gfortran.dg/pr91552.f90, e.g.

  print *, 2 * [real :: 1, [2], 3]

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

[mikael at gcc dot gnu.org]

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

--- Comment #18 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #14)
> 
> 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?

Well, a new return code seems better (ARITH_INVALID_TYPE ?).
I think it's better to move the check to the various gfc_arith_times,
gfc_arith_plus, gfc_arith_concat etc, because only those functions know what
type is appropriate and what is not.
Admittedly BT_UNKNOWN is probably never appropriate, and the check could be
done in reduce_binary_ac, but then it should be in reduce_binary_ca,
reduce_binary_aa and reduce_unary as well.
Then what's missing is a goto runtime in eval_intrinsic if evaluation returns
ARITH_INVALID_TYPE.
That's the first solution.

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

[mikael at gcc dot gnu.org]

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

--- Comment #19 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #17)
> (In reply to anlauf from comment #16)
> > Created attachment 53651 [details]
> > Revised patch
> 
> Unfortunately this regresses on gfortran.dg/pr91552.f90, e.g.
> 
>   print *, 2 * [real :: 1, [2], 3]

Yes, verify_types misses a call to itself for every element that is an array.
I think we should not reject all mismatching types, because there is a call to
gfc_type_convert_binary further down that is able to handle conversions on
numeric types.  Basically all numeric types, even if mismatching, should work.
That's the second solution.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53651|0                           |1
        is obsolete|                            |

--- Comment #20 from anlauf at gcc dot gnu.org ---
Created attachment 53659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53659&action=edit
Next try.

(In reply to Mikael Morin from comment #18)
> Well, a new return code seems better (ARITH_INVALID_TYPE ?).
> I think it's better to move the check to the various gfc_arith_times,
> gfc_arith_plus, gfc_arith_concat etc, because only those functions know what
> type is appropriate and what is not.
> Admittedly BT_UNKNOWN is probably never appropriate, and the check could be
> done in reduce_binary_ac, but then it should be in reduce_binary_ca,
> reduce_binary_aa and reduce_unary as well.
> Then what's missing is a goto runtime in eval_intrinsic if evaluation
> returns ARITH_INVALID_TYPE.
> That's the first solution.

Here's a patch that introduces ARITH_INVALID_TYPE and handles errors in
reduce_unary, reduce_binary_ac, reduce_binary_ca, and reduce_binary_aa.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org

--- Comment #21 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058280.html

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #22 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Oct 04, 2022 at 09:20:33PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #21 from anlauf at gcc dot gnu.org ---
> Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058280.html
> 

Thanks Harald!

In looking at the patch, there is a 

   gcc_assert (op1->ts.type != BT_UNKNOWN);

in reduce_binary_ac() near line 1334 and

   gcc_assert (op2->ts.type != BT_UNKNOWN);

in reduce_binary_ca() near line 1386 that
I think can go away.

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

[anlauf at gcc dot gnu.org]

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

--- Comment #23 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #22)
> In looking at the patch, there is a 
> 
>    gcc_assert (op1->ts.type != BT_UNKNOWN);
> 
> in reduce_binary_ac() near line 1334 and
> 
>    gcc_assert (op2->ts.type != BT_UNKNOWN);
> 
> in reduce_binary_ca() near line 1386 that
> I think can go away.

You're probably right, although I'm not entirely sure that there is a
corner case that we haven't covered yet...

I think it doesn't really harm to leave it there for now.
Gerhard will tell (fingers crossed...).

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:705ed42a1ad950860f46c51216ff69dbe0f4857a

commit r13-3176-g705ed42a1ad950860f46c51216ff69dbe0f4857a
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Tue Oct 4 23:04:06 2022 +0200

    Fortran: error recovery for invalid types in array constructors [PR107000]

    gcc/fortran/ChangeLog:

            PR fortran/107000
            * arith.cc (gfc_arith_error): Define error message for
            ARITH_INVALID_TYPE.
            (reduce_unary): Catch arithmetic expressions with invalid type.
            (reduce_binary_ac): Likewise.
            (reduce_binary_ca): Likewise.
            (reduce_binary_aa): Likewise.
            (eval_intrinsic): Likewise.
            (gfc_real2complex): Source expression must be of type REAL.
            * gfortran.h (enum arith): Add ARITH_INVALID_TYPE.

    gcc/testsuite/ChangeLog:

            PR fortran/107000
            * gfortran.dg/pr107000.f90: New test.

    Co-authored-by: Mikael Morin <mikael@gcc.gnu.org>

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |13.1.0
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #25 from anlauf at gcc dot gnu.org ---
Fixed in gcc-13.