public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "pault at gcc dot gnu.org" <gcc-bugzilla@gcc.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	[thread overview]
Message-ID: <bug-98498-4@http.gcc.gnu.org/bugzilla/> (raw)

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


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

             reply	other threads:[~2021-01-02  9:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-02  9:41 pault at gcc dot gnu.org [this message]
2021-01-02  9:42 ` [Bug fortran/98498] " pault at gcc dot gnu.org
2021-01-03 12:22 ` pault at gcc dot gnu.org
2023-11-03  7:11 ` cvs-commit at gcc dot gnu.org
2023-11-03  7:15 ` pault at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-98498-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).