From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7AAC83858403; Fri, 30 Sep 2022 20:26:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7AAC83858403 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664569600; bh=+398HzaLTErnL4zlvuAmdKSpxKkgh1tyDi/JBu1IJW0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pPLUkLvrhOCQXe5zB7Gb983JeU2JKpcAvmQ0Rs0m4PuCC7+tv4vtlpzI4kLSIFw4S Vs4IhoheiajSvMMYGingOZ66MccdndJ4uQHBrFLjseNPsYim6Wx8Id9cpQqQ0+8/Ji pmFhEpy+OaQt+c/l11MSGiTh6rouoz9ixp5wR+6s= From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243 Date: Fri, 30 Sep 2022 20:26:40 +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: sgk at troutmask dot apl.washington.edu 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107000 --- Comment #15 from Steve Kargl = --- 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=3D107000 >=20 > --- 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 bo= th) > > of the operands is an array, we do numerical evaluation for every eleme= nt of > > the array. > >=20 > > With the guarding check above, it is safe, with the assumption that ele= ments > > of an array have the same type as the array itself. If that condition = is > > not true, well, it doesn't work obviously. > >=20 > > 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 v= iew. >=20 > 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. >=20 > This patch tried to perform checks in reduce_binary_ac, but I was not hap= py > with that particular implementation. >=20 > When looping over the elements, we currently have >=20 > gfc_simplify_expr (c->expr, 0); >=20 > if (c->expr->expr_type =3D=3D EXPR_CONSTANT) > rc =3D eval (c->expr, op2, &r); > else > rc =3D reduce_binary_ac (eval, c->expr, op2, &r); >=20 > and do not handle the case that c->expr->ts.type =3D=3D BT_UNKNOWN. > Should we return sth. like rc =3D ARITH_INCOMMENSURATE, except that it is > not array .op. array? >=20 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=20 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.=