From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F239E3858C52; Wed, 28 Feb 2024 20:24:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F239E3858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709151856; bh=TEFPZtWdqmG1R+rVR79RjXilVG+91LeLWMW2omlJbng=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bWJC7ZeNKmOafVsU0MFixHouFVIaDwksyhgXSGFg5JAj8aZL2CdwT8lTHdWFcs552 hNyfnoYdP5CVDOw9qjQ73tq9VdVszy+3ogEH2PYsgHX/kmYANyK9K/19ndyL3PxYhp eq7N4IRMlxvwX+R+JGcaTpTQjrwcqoUPff0aQnoQ= From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function Date: Wed, 28 Feb 2024 20:24:16 +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: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P5 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=3D114141 --- Comment #7 from Steve Kargl -= -- On Wed, Feb 28, 2024 at 07:27:24PM +0000, mikael at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114141 >=20 > --- Comment #6 from Mikael Morin --- > (In reply to kargl from comment #5) > > (In reply to Mikael Morin from comment #4) > >=20 > > > (In reply to kargl from comment #3) > > > > Yep, agreed. I went back an re-read the section about ASSOCIATE. > > > > Not sure how I convinced myself that a constant expression, which > > > > reduces to a constant is okay. > > > >=20 > > > Not sure how you convinced yourself it isn't. ;-) > >=20 > > x =3D> log(cmplx(-1,0)) > >=20 > > R1104 association is associate-name =3D> selector > >=20 > > R1105 selector is expr > > or variable > >=20 > > R902 variable is designator > > or function-reference > >=20 > > R901 designator is object-name > > or array-element > > or array-section > > or coindexed-named-object > > or complex-part-designator > > or structure-component > > or substring > >=20 > > log(cmplx(-1,0)) is certainly not a designator. > >=20 > > log(cmplx(-1,0)) is a function-reference. But this then > > leads to > >=20 > > C902 (R902) function-reference shall have a data pointer result. > >=20 > >=20 > > log(cmplx(-1,0)) violates C902, so this then means that it > > must be an expr. > Agreed. >=20 > > One now needs > >=20 > >=20 > > R915 complex-part-designator is designator % RE > > or designator % IM > >=20 > > C922 (R915) The designator shall be of complex type. > >=20 > > which shows that expr%im is invalid; even though log(cmplx(-1,0)) > > reduces to a constant (i.e., it's not a named constant. This > > is likely the error [pun intended] in my ways.). > >=20 > This is about x%im, which is a different expression from log(cmplx(-1, 0)= ). > x is an associate-name, and thus (I think) an object-name, and a valid > designator, even if it's associated selector isn't. >=20 Indeed. Bit more reading of F2023, 11.1.3 agrees with you. 11.1.3.1 The ASSOCIATE construct associates named entities with expressions or variables during the execution of its block. These named construct entities (19.4) are associating entities (19.5.1.6). The names are associate names. 11.1.3.3(5) The associating entity itself is a variable, but ... The "but ..." applies to whether the selector is a definable variable. So, 'y =3D x%im' is allowed, but 'x%im =3D 42' is disallowed because the selector is not definable. Interesting twist. This then=20 suggests that Jerry's use of parentheses should be accepted.=