From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C63E5385C404; Fri, 30 Sep 2022 12:45:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C63E5385C404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664541931; bh=KQ4XQuyCkwgHgBCcZvl+SP8bVmkRZLrGGK2uC53k4Zs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I+Oynqnx8KlUBCjnM2mcTiAs9xnPd02OZozPwPstNtRus/XXC4bZyZAEbmdJbZFED 4V6MkY7C27+a6FsceypB/pVkmaEmlnX1/E1z0718maSivxyaLa43QARhtKHcwitc7f 2uuEjkW9ZwE/ZYEj1XAS33abo6jw0QiP8lb0JRV0= From: "mikael at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243 Date: Fri, 30 Sep 2022 12:45:30 +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: mikael 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: cc 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 Mikael Morin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikael at gcc dot gnu.org --- Comment #13 from Mikael Morin --- 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 t= he array. With the guarding check above, it is safe, with the assumption that element= s 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.=