[Bug fortran/98498] New: Interp request: defined operators and unlimited polymorphic

[Bug fortran/98498] New: Interp request: defined operators and unlimited polymorphic

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498

            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=20) :: name
     integer           :: level
  end TYPE pvar

  interface operator (==)
     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 = .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 = .true.
          else
            pvar_eq = .false.
          end if
      end select
      class default
        print *, "class default: returning false"
        pvar_eq = .false.
    end select
  end function pvar_eq
end MODULE mytypes

program test_eq
   use mytypes
   implicit none
   type(pvar) x, y
   x = pvar('test 1', 100)
   y = pvar('test 1', 100)
   write(*, *) x == y
   x = pvar('test 1', 100)
   y = pvar('test 2', 100)
   write(*, *) x == 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 
arguments shall be consistent with the intrinsic uses of that operator, 
and the types, kind type parameters, or ranks of the dummy arguments 
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 
(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 
that identifier have the same number of arguments, one shall have a 
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 
operator follows the same rules as other generic extensions. The 
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. 
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 
ranks of the" and replace "replace "differ from" with "be distinguishable 
from", with "distinguishable" linked to 15.4.3.4.5 (Restrictions on 
generic declarations). The sentence now reads:

"If the operator is an intrinsic-operator (R608), the number of dummy 
arguments shall be consistent with the intrinsic uses of that operator, 
and the dummy arguments shall be distinguishable from those required 
for the intrinsic operation (10.1.5)."

SUBMITTED BY: Steve Lionel

HISTORY: yy-nnn    m223  F08/nnnn submitted


----------------------------------------------------------------------

[Bug fortran/98498] Interp request: defined operators and unlimited polymorphic

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-01-02
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

[Bug fortran/98498] Interp request: defined operators and unlimited polymorphic

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 49869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49869&action=edit
Fix pending the iterpretation request

! { dg-do compile }
! { dg-options "-fdump-tree-original" }
!
! gfortran.dg/interface_49.f90
! Tests the fix for PR98498 in which the '==' operator interface was not
! applied to intrinsic type/kind expressions. This meant that the
! interface was not applied to the .eq. expressions in 'star_eq' even
! though the unlimited polymorphic dummies are type compatible with all
! entities. The tree dump used to contain 10 'star_eq's.
!
! Note that overridding intrinsic operators with functions that have
! compliant intrinsic dummies still yields the error "Operator interface
! at (1) conflicts with intrinsic interface", as required by
! F2003(12.3.2.1.1).
!
! Contributed by Paul Thomas  <pault@gcc.gnu.org>
!
MODULE mytypes
  IMPLICIT none

  TYPE pvar
     character(len=20) :: name
     integer           :: level
  end TYPE pvar

  interface operator (==)
     module procedure star_eq
  end interface

contains
  RECURSIVE function star_eq(a,b) ! The recursive attribute should not be
required.
    implicit none
    class(*), intent(in) ::a,b
    logical ::star_eq
    if (.not. same_type_as (a, b)) then
      star_eq = .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
            star_eq = .true.
          else
            star_eq = .false.
          end if
      end select
      class default
        print *, "class default: returning false"
        star_eq = .false.
    end select
  end function star_eq

end MODULE mytypes

program test_eq
   use mytypes
   implicit none

   type(pvar) x, y
   x = pvar('test 1', 100)
   y = pvar('test 1', 100)
   write(*, *) x == y
   x = pvar('test 1', 100)
   y = pvar('test 2', 100)
   write(*, *) x == y
end program test_eq
! { dg-final { scan-tree-dump-times "star_eq" 12 "original" } }

[Bug fortran/98498] Interp request: defined operators and unlimited polymorphic

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:8c8ad4e3533b8590ce063386b8b32f6fce1c3942

commit r14-5094-g8c8ad4e3533b8590ce063386b8b32f6fce1c3942
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Fri Nov 3 07:11:12 2023 +0000

    Fortran: Defined operators with unlimited polymorphic args [PR98498]

    2023-11-03  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/98498
            * interface.cc (upoly_ok): Defined operators using unlimited
            polymorphic formal arguments must not override the intrinsic
            operator use.

    gcc/testsuite/
            PR fortran/98498
            * gfortran.dg/interface_50.f90: New test.

[Bug fortran/98498] Interp request: defined operators and unlimited polymorphic

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|WAITING                     |RESOLVED

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on mainline.

Paul