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 526DE3858C00; Thu,  1 Sep 2022 22:03:39 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 526DE3858C00
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1662069819;
	bh=q6qSuwgzYtGkZwzsDI0MrIKLqqQT96QvPvhS/Qy8LXY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ZJlErYnEp2DTMn9TTGXp7ZznZd4hqHod7Ndn0H2FexKI0/Oq/N0jhzdB7jwYbMjHj
	 n3tkIRZCnp7oA84W31+j2qKQTbI74mr12DO+50z5STbLabMyjzRAnxeorMT6f2oNMS
	 Fw27p1l/NOz1ZXK27BaCBvIPdDC8Rk/ZIFKRaOCU=
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/99349] ICE in match_data_constant, at
 fortran/decl.c:426
Date: Thu, 01 Sep 2022 22:03:39 +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: 11.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: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-99349-4-OTOPkctMi3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-99349-4@http.gcc.gnu.org/bugzilla/>
References: <bug-99349-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=3D99349

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> -=
--
On Thu, Sep 01, 2022 at 07:57:56PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99349
>=20
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #4)
> > The function is match_data_constant(), so we're looking for a
> > constant.  My patch simply removes the type checking as it is
> > unimportant here, and a type mismatch between a data-object and
> > data-value is checked elsewhere.  I suspect my original code was
> > being too cautious with type checks.
>=20
> There's nothing wrong with being cautious.  Currently, the only valid
> parameter inquiries are %kind, %len, %re, %im.  So checking for integer
> or real makes sense.
>=20

Ah, that rings a bell.  'git blame' shows that I added the
integer check and pault added the real check.  I suspect
only %kind and %len were available when I added the original
code, and pault added the real check when he implemented
%im and %re.

Keeping the checks is ok with me and your patch does the
job.=