From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by sourceware.org (Postfix) with ESMTPS id 1D889385802A for ; Sat, 2 Jan 2021 09:45:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1D889385802A Received: by mail-lf1-x136.google.com with SMTP id a12so52629061lfl.6 for ; Sat, 02 Jan 2021 01:45:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HT9PR+iGEU8xFxvB3YIUXj8N0ItFVIfKVf94XOtxN+M=; b=ktplx2MV9VCcrXKMrhW2mviOMNQcXQ55fiTDa9PzAJosT5c4iRe+atHhRkOIINKI2r l1yz4hia88NCdtvZToKQHX4l/NZK/5FqWbUAplvlmT8JnvpLb1/g5vhJOjIsPE3kS0Re bZTBJhbhRkSfjmKg6/NciOrGoA0mStPEfwroogzzmaLvmyhFoZKCqC1MRwJNdIoPFNuG OAnQ2fgDQkZvInvMxPTuXD26pDTUh8cyWIafIZCuYiHSAcji2nyDK4EfVhyWMXh5TpTb uI1/EL+XDl6D7pNU3jKf+OAE7dLyd+OafHq9p+f5U9+YomAxO+979EyVCLStCkwcYGo1 fiag== X-Gm-Message-State: AOAM531sw7FEJQIXt+OOeYWI529tYyMnRJXF7p81uyP6bNOUT3dXyZxq R5jq2b1djYUkhwH3S+y1ySOof/u3W41vyAX2iXJd57iX4IA= X-Google-Smtp-Source: ABdhPJyQXQlryINi7a9FRE53pE6wdKamVyt+aw7bhpH9KAgmgJr+Uvo7wpn5l9vnsUFh3eqIq5c08Enj2jIP4aKa7gI= X-Received: by 2002:a2e:2417:: with SMTP id k23mr31308454ljk.373.1609580716557; Sat, 02 Jan 2021 01:45:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Paul Richard Thomas Date: Sat, 2 Jan 2021 09:45:04 +0000 Message-ID: Subject: Re: Overriding intrinsic operators To: "fortran@gcc.gnu.org" Cc: Steve Lionel X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2021 09:45:19 -0000 This is now PR98498. I have set its status to "waiting", pending an interpretation request. Paul On Fri, 1 Jan 2021 at 18:20, Steve Lionel wrote: > On 1/1/2021 11:14 AM, Paul Richard Thomas wrote: > > This comes about because ifort is using the defined operation to override > the intrinsic uses of the operator as defined in 10.1.5 of the standard. > > I believe that gfortran has this one right, since the first paragraph of > 15.4.3.4.2 Defined operations has: > "...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)." > > This is a fascinating issue, but I am afraid I must be the bearer of bad > news - I believe ifort is more right here than gfortran; but I also think > there is need for an interpretation. > > > Look at this in terms of the rules for generic interfaces that specify > whether signatures are distinguishable (15.4.3.4.5). We'll start with: > > 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. > > In equals4.f90, you have a defined operator for == with class(*) dummy > arguments. The text in 15.4.3.4.2 that says [TKR] "shall differ" really > wants to say "is distinguishable from". class(*) objects have no type and > they are type compatible with EVERYTHING! So ifort is not wrong to call the > defined operator procedure for comparing integers (or in equals5, character > strings.) I think the standard needs to use different wording than "shall > differ" and I'll write up an interp about it. Intrinsic operations should > be considered built-in generic interfaces that can be "extended", and that > the rules for distinguishing generics should apply to defined operators. > > > The reason that equals4 works when the defined operator declaration is > moved to the main program is that it no longer applies to pvar_eq. > > > In support of my position, I observe that NAG Fortran 7.0.7036 behaves > identically here to ifort, including, for equals5, having star_eq > recursively call itself until it runs out of stack. I believe that the > correct resolution is that declaring a defined operator with class(*) dummy > arguments is a violation of C1511 and should be diagnosed by compilers. I > know this is not the answer the c.l.f poster wants to hear. > > > ifort DOES have a bug exposed by equals5.f90, in that it complains that > star_eq is called recursively. As a claimed F18-conforming compiler, > star_eq is RECURSIVE by default. I will report that to Intel. > > > Steve > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein