From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F3432385803B; Sat, 2 Jan 2021 09:41:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F3432385803B From: "pault at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/98498] New: Interp request: defined operators and unlimited polymorphic Date: Sat, 02 Jan 2021 09:41:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pault 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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, 02 Jan 2021 09:41:36 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98498 Bug ID: 98498 Summary: Interp request: defined operators and unlimited polymorphic Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- It looks as if gfortran is standard defying; J3/yy-nnn To: J3 Members From: Steve Lionel Subject: F2018 interp: Extending intrinsic operator with class(*) dummies Date: 01-Jan-2021 ---------------------------------------------------------------------- NUMBER: F08/ ! /interp assigns number after submission TITLE: Extending intrinsic operator with class(*) dummies KEYWORDS: unlimited polymorphic, defined operator, intrinsic operator DEFECT TYPE: ! /interp assigns STATUS: J3 consideration in progress QUESTION: Consider the following program (created by Paul Richard Thomas): MODULE mytypes IMPLICIT none TYPE pvar character(len=3D20) :: name integer :: level end TYPE pvar interface operator (=3D=3D) module procedure pvar_eq end interface contains function pvar_eq(a,b) implicit none class(*), intent(in) ::a,b logical ::pvar_eq if (.not. same_type_as (a, b)) then pvar_eq =3D .false. return end if select type (a) type is (pvar) select type (b) type is (pvar) print *, "a & b are type pvar" if((a%level.eq. b%level) .and. (a%name .eq. b%name)) then !A pvar_eq =3D .true. else pvar_eq =3D .false. end if end select class default print *, "class default: returning false" pvar_eq =3D .false. end select end function pvar_eq end MODULE mytypes program test_eq use mytypes implicit none type(pvar) x, y x =3D pvar('test 1', 100) y =3D pvar('test 1', 100) write(*, *) x =3D=3D y x =3D pvar('test 1', 100) y =3D pvar('test 2', 100) write(*, *) x =3D=3D y end program test_eq The intrinsic equality operator is extended with a function where both dummy arguments are unlimited polymorphic. Three compilers accept this; two use the extension for comparisons of any type, such as the one between two integers at "!A" - the other applies the intrinsic meaning to the integer comparison. 15.4.3.4.2p1 (Defined operation) says: "If the operator is an intrinsic-operator (R608), the number of dummy=20 arguments shall be consistent with the intrinsic uses of that operator,=20 and the types, kind type parameters, or ranks of the dummy arguments=20 shall differ from those required for the intrinsic operation (10.1.5)." The phrase "shall differ" here is not the same as in 15.4.3.4.5=20 (Restrictions on generic declarations) which instead talks about TKR compatibility and the ability to "distinguish" dummy arguments. "C1511 Within the scope of a generic operator, if two procedures with=20 that identifier have the same number of arguments, one shall have a=20 dummy argument that corresponds by position in the argument list to a dummy argument of the other that is distinguishable from it." Was it intended that the standard treat extending intrinsic operators in a different manner than other generic interfaces? If so, how should this program be interpreted? ANSWER: No, such a treatment was not intended. Extending a generic intrinsic=20 operator follows the same rules as other generic extensions. The=20 example program violates C1511 in that the unlimited polymorphic dummy arguments are not distinguishable from arguments of any type for which the intrinsic operator is valid (Table 10.2). Consider also Note 1 in 10.1.6.1 (Defined Operations > Definitions) says: "An intrinsic operator can be used as the operator in a defined operation.= =20 In such a case, the generic properties of the operator are extended" An edit is proposed to correct the deficiency. EDITS to 18-007r1: [295:10, 15.4.3.4.2 (Defined operations)] In the last sentence, remove the text "types, kind type parameters, or=20 ranks of the" and replace "replace "differ from" with "be distinguishable=20 from", with "distinguishable" linked to 15.4.3.4.5 (Restrictions on=20 generic declarations). The sentence now reads: "If the operator is an intrinsic-operator (R608), the number of dummy=20 arguments shall be consistent with the intrinsic uses of that operator,=20 and the dummy arguments shall be distinguishable from those required=20 for the intrinsic operation (10.1.5)." SUBMITTED BY: Steve Lionel HISTORY: yy-nnn m223 F08/nnnn submitted ----------------------------------------------------------------------=