From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BC1DE3892474; Sat, 12 Dec 2020 16:34:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BC1DE3892474 From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe Date: Sat, 12 Dec 2020 16:34:06 +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: pault at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.4 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 16:34:06 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98022 --- Comment #7 from Steve Kargl -= -- On Sat, Dec 12, 2020 at 04:02:54PM +0000, pault at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98022 >=20 > --- Comment #6 from Paul Thomas --- > (In reply to kargl from comment #4) > > (In reply to Paul Thomas from comment #3) > >=20 > > > function kn1() result(hm2) > > > complex :: hm(1:2), hm2(1:2) > > > data (hm(md)%re, md=3D1,2)/1.0, 2.0/ > > > hm2 =3D hm > > > end function kn1 > >=20 > > Are you sure that this is valid Fortran? I cannot > > find anything in the Fortran standard that says hm%im > > is defined. Thus, 'hm2=3Dhm' is referencing a variable > > that is no completely defined. > >=20 > >=20 > > 19.6.1 Definition of objects and subobjects > >=20 > > 2 Arrays, including sections, and variables of derived, character, > > or complex type are objects that consist of zero or more subobjects. > > Associations may be established between variables and subobjects and > > between subobjects of different variables. These subobjects may become > > defined or undefined. > >=20 > > 5 A complex or character scalar object is defined if and only if all > > of its subobjects are defined. >=20 > Hi Steve, >=20 > I saw your comment a bit too late. I think that you are correct. I guess = that, > at very least, I should not zero out the undefined part of the complex ob= ject? > That way it would be equivalent to using assignment to achieve the same t= hing > or to partially define a derived type. >=20 > I'll post on clf. >=20 I recall looking at this PR a long time ago, but came up empty with ideas on how to fix it. You've some made some progress. It gets messy (at least to me) to determine if it is valid, and comes from reading 8.6.7 "Data statement", carefully. One gets to=20 A data-stmt-constant other than boz-literal-constant, null-init, or initial-data-target shall be compatible with its corresponding variable according to the rules of intrinsic assignment (10.2.1.2). The variable is initially defined with the value specified by the data-stmt-constant; if necessary, the value is converted according to the rules of intrinsic assignment (10.2.1.3) to a value that agrees in type, type parameters, and shape with the variable. Now, we go to "what is a variable?" R902 variable is designator R901 designator is ... or complex-part-designator ... R915 complex-part-designator is designator % RE or designator % IM In your example, hm%re is real, so the rules for intrinsic assignment to a real applies. Of course, I could be wrong.=