From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 129843858016; Wed, 28 Sep 2022 18:22:17 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 129843858016
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1664389337;
	bh=iBDHCF7hoTMinsehy2bp7hi9IHRA9cgxUCnCRHvq81k=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=xA9RgHLmLrBipt/vcMd0x5P0einIYSGbpIaee9Vsst3BmZ+quzl8nr96JEAdjFZWC
	 wyj9I9ivTKMNBSndJ4DH2won6PnorEa+mius8olaqeHMkFk0K/IynnFNtEI1KgZJq7
	 QPrUSvFOzLzYMEVeYzEULDt91C+85FbRaNrWL4Wc=
From: "kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/107000] ICE in gfc_real2complex, at
 fortran/arith.cc:2243
Date: Wed, 28 Sep 2022 18:22:16 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kargl at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107000-4-obINwlGDsb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107000-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107000-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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'.
>=20
> I played some more and found that we would regress on e.g.
>=20
>   print *, [real :: 1, +real(2.0)]
>=20
> while
>=20
>   print *, [real :: 1,  real(2.0)]
>=20
> is fine.
>=20
> 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 =3D gfc_constructor_first (head); c; c =3D gfc_constructor_next (=
c))
     {
       e =3D c->expr;
+
+      /* Special case unary operators to catch [real :: +'1'].  */
+      if (e->expr_type =3D=3D EXPR_OP && e->ts.type =3D=3D BT_UNKNOWN)
+       {
+         gfc_expr *op1 =3D e->value.op.op1;
+         if ((op1->value.op.op =3D=3D INTRINSIC_UMINUS
+              || op1->value.op.op =3D=3D 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 =3D=3D EXPR_ARRAY && e->ts.type =3D=3D BT_UNKNOWN
          && !e->ref && e->value.constructor)
        {

Unfortunately, it ICEs with=20

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