From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9B5B23858C66; Fri, 1 Mar 2024 17:28:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B5B23858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709314087; bh=/glyNiltF+JrUeyjHELgpg1lSKWaXAJrPD3f5awY0MY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XmdBmUz+ihv4GXIehh1dg4hBemItXLKOvEiQDQ7ch+WJvuz006SeQVorY7IdGFPn3 SZlpQX8zAb6fRaiEjtjZTmRxEuePuKAPfYuepW87NtEMyKejzcwPvUZ2jdlGfb7Bcd vpK0VhULLob+5MsVX4LOmUPfAfnFzEg3ikDSYTLI= From: "kargl at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/114188] Overloading assignment does not invalidate intrinsic assignment Date: Fri, 01 Mar 2024 17:28: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: 13.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kargl at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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=3D114188 kargl at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Bader@lrz.de from comment #0) > Created attachment 57583 [details] > test case for invalid use of assignment overloading >=20 > The attached reproducer overloads the assignment operator with a version > that requires the left hand side to be a pointer. >=20 > The overload conforms to the requirements for defining the assignment > according to 10.2.1.4 of the Fortran standard. Therefore, the intrinsic > assignment should become unavailable (last sentence of 10.2.1.1). >=20 > However, gfortran accepts invocations that use nonpointer arguments. >=20 > (NAG Fortran, Intel Fortran and NVidia Fortran issue appropriate error > messages). Can you provide a bit more detail in your interpretation of F2023? The last sentence in 10.2.1.1 is=20 1 An assignment-stmt shall meet the requirements of either a defined assignment statement or an intrinsic assignment statement. If I comment out your 'interface assignment(=3D)' block, then 'b =3D a' is an intrinsic assignment. If I replace 'b =3D a' with the direct call to 'ass', I see a.f90:26:12: 26 | call ass(b, a) | 1 Error: Actual argument for =E2=80=98to=E2=80=99 at (1) must be a pointer or= a valid target for the dummy pointer in a pointer assignment statement which seems to be the error that you want. The question is then if the source of this error can be interpreted such that 'b =3D a' in your original code is in fact not a defined assignment, and therefore, it is an intrinsic assignment (last sentence in 10.2.1.1). 10.2.1.5 has 1 The interpretation of a defined assignment is provided by the subroutine that defines it. and the NOTE in this section contains=20 The rules of defined assignment (15.4.3.4.3), ... 15.4.3.4.3 goes into some detail about argument association. These rules seem to be the source of the above error when 'ass' is called directed. Unfortunately, the five requirements in 10.2.1.4 for defined assignment do not say anything about argument association.=