From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id BFF8E389203B for ; Fri, 16 Apr 2021 11:02:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BFF8E389203B Received: by mail-lf1-x12a.google.com with SMTP id n8so44218314lfh.1 for ; Fri, 16 Apr 2021 04:02:38 -0700 (PDT) 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=NqH01y1Y4mefzhLVk657WFeof1zM5HLgAHd4vLq6dk0=; b=IV6vBl3M+6e+d0lZqdfbKIN0mXAej+1Gk3FLPyAeFNFWRwAuICFZPFr3KmbYOK8xE9 Sfr1huCAY3yM+5/whxcc5gZXFf1YqEdL1/RYlWVpxp/Xm8h8/c43GBc1V9LN9ycwV1VA /AeNVv24vrP5I8ZvdDEySNXqLhCVZASnQqgPTcufBt6AScazX7Vdy9m1JUIlH573LpaG Gj0yQKmg9scu4u88Z1UhprHbokgjXk2FJ88IykIJ9Bi/pYIpCcDvVd8/Y9S586NiYonA G4gzVDQysJkEfdg24kw3YOF43xTYCHwp/9X5q0z65umvLEqct/iBmfiN6RVZOXHobAre cn1g== X-Gm-Message-State: AOAM5313iw44w79X3bHKBBNQW6KCGAzC5c7rEK/ZFSK+1AYEfVKg7obF b4wyaofURCpQatcvIwnD2JT+AxKsu4jUYYctB6w= X-Google-Smtp-Source: ABdhPJwcatmrFvf3gUiN90v5ZtGiufDBhD4og3dAqOSjkxcKaC8AqzgzwU1MVGQ4649hoocU6zdBQioWyx8ji9CfvUI= X-Received: by 2002:ac2:4192:: with SMTP id z18mr2531300lfh.19.1618570957492; Fri, 16 Apr 2021 04:02:37 -0700 (PDT) MIME-Version: 1.0 References: <20210416090600.5f1da58a@nbbrfq> In-Reply-To: From: Paul Richard Thomas Date: Fri, 16 Apr 2021 12:02:26 +0100 Message-ID: Subject: Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt' To: Bernhard Reutner-Fischer Cc: Harald Anlauf via Fortran , Harald Anlauf X-Spam-Status: No, score=-2.0 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: Fri, 16 Apr 2021 11:02:40 -0000 Hi Harald, This is the output from a completely tedious Zoom meeting: /* From F2003 onwards, intrinsic procedures are no longer subject to the restriction, "that an elemental intrinsic function here be of type integer or character and each argument must be an initialization expr of type integer or character" is lifted so that intrinsic procedures can be over-ridden. This requires that the intrinsic symbol not appear in the module file, thereby preventing ambiguity when USEd. */ if (strcmp (sym->module, "(intrinsic)") == 0 && (gfc_option.allow_std & GFC_STD_F2003)) return; Modify or replace the comment, as desired. The change to the condition gives the desired result in terms of standard compliance. Regards Paul On Fri, 16 Apr 2021 at 09:32, Paul Richard Thomas < paul.richard.thomas@gmail.com> wrote: > Hi All, > > Harald, that is to say the least of it an elegant and minimalist fix. With > the patch applied, gfortran behaves like the "other brand" and regtests OK. > > Bernhard correctly points out that there should be a comment. Not only > this, there must be an F2003 standard check, since F95 forbids over-riding > of elemental intrinsics. > > I see as I am writing that Tobias has dealt with the point about module > version. I agree entirely with Tobias. The fact that the patch is > permissive in suppressing an incorrect error means that it cannot break > anything. > > This patch, once modified as above, should be pushed to master right > immediately and, since it affects F2003 compliance, backported to 10-branch. > > Many thanks, Harald - good work! > > Paul > > > > > > On Fri, 16 Apr 2021 at 08:41, Bernhard Reutner-Fischer via Fortran < > fortran@gcc.gnu.org> wrote: > >> On Thu, 15 Apr 2021 22:52:01 +0200 >> Harald Anlauf via Fortran wrote: >> >> > Hello everybody, >> > >> > we currently write the interface for intrinsic procedures to module >> > files although that should not be necessary. (F2018:15.4.2.1 actually >> > states that interfaces e.g. of intrinsic procedures are 'explicit'.) >> > This lead to bogus errors due to an apparently bogus ambiguity. >> > A simple solution is to just avoid writing that (redundant) information >> > to the module file. >> >> I'd put the standard reference you cite in a comment before the check. >> >> Does this change the module format in an incompatible way, i.e. does >> this require a module format version bump? >> >> What happens when we read an existing module that names an intrinsic? >> Without bumping the module version, we'd run into the same issue as >> before, don't we? >> >> If we did not bump the module version yet for gcc-11 then i would >> suggest to defer the patch for gcc-12 and bump then. >> >> Even if we'd skip reading existing intrinsic now, we'd break interop >> with older compiler versions if we would stop writing them without >> bumping the module format, i think? >> >> > Regtested on x86_64-pc-linux-gnu. OK for (current) mainline? >> > Or rather wait after 11 release? >> > >> > Thanks, >> > Harald >> > > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein