From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E168B3858D32; Sun, 2 Oct 2022 20:05:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E168B3858D32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664741147; bh=FIu+QrfCwjly+fC5YGk64BxYPTc9vyGP2U4D8OJiwmo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BxjzzssjKUjUSGy8NP3VUcJHixVlHEbuVV5WRRLR2A7ahyvoGTml2Fhxzq++s6iWH xtJUWmTln3Mlh3gadcPZPO1580HDKSVIINHxjInvIPhh/wq4xXl6WDCPiFITKC49Cy /2fmsO4a1gG9v/MWXxuQxYJ8HafSjQMmgdgRR7VU= From: "anlauf 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: Sun, 02 Oct 2022 20:05:46 +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: anlauf 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: attachments.isobsolete attachments.created 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 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=3D53651&action=3Dedit 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?=