From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102760 invoked by alias); 12 Jul 2018 14:35:34 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 102294 invoked by uid 89); 12 Jul 2018 14:35:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT autolearn=no version=3.3.2 spammy=typical, achieving, sticking, H*f:sk:3D4B88C X-HELO: nef2.ens.fr Received: from nef2.ens.fr (HELO nef2.ens.fr) (129.199.96.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jul 2018 14:35:31 +0000 X-ENS-nef-client: 129.199.120.1 Received: from mailhost.lps.ens.fr (tournesol.lps.ens.fr [129.199.120.1]) by nef2.ens.fr (8.13.6/1.01.28121999) with ESMTP id w6CEZSO8069409 ; Thu, 12 Jul 2018 16:35:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailhost.lps.ens.fr (Postfix) with ESMTP id A659614B; Thu, 12 Jul 2018 16:35:28 +0200 (CEST) Received: from mailhost.lps.ens.fr ([127.0.0.1]) by localhost (tournesol.lps.ens.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNEeyN03Bww9; Thu, 12 Jul 2018 16:35:28 +0200 (CEST) Received: from [192.168.1.11] (log78-1-82-242-47-10.fbx.proxad.net [82.242.47.10]) by mailhost.lps.ens.fr (Postfix) with ESMTPSA id 6B75D14A; Thu, 12 Jul 2018 16:35:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions From: =?utf-8?Q?Dominique_d=27Humi=C3=A8res?= In-Reply-To: Date: Thu, 12 Jul 2018 14:35:00 -0000 Cc: gfortran , gcc-patches Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D4B88C8-39B3-4E6C-9FA0-4EB6F80788B5@lps.ens.fr> To: Janus Weil X-SW-Source: 2018-07/txt/msg00021.txt.bz2 > Le 12 juil. 2018 =C3=A0 16:12, Janus Weil a =C3=A9cri= t : >=20 > Hi Dominique, >=20 > thanks for the comments. >=20 >>> after the dust of the heated discussion around this PR has settled a >>> bit, here is another attempt to implement at least some basic warnings >>> about compiler-dependent behavior concerning the short-circuiting of >>> logical expressions. =E2=80=A6 >>=20 >> IMO your patch is missing the only point I agree with you on this issue,= i.e., >=20 > So you don't agree that it's a good idea to warn about non-portable code? Wel, as you might guess I don=E2=80=99t like warnings in general: too much = false positives and missed targets (see recent bootstrap breakage). >=20 >> the short-circuit evaluation and the related portability issues should be >> documented. >=20 > I fully agree. Documentation never hurts. Do you have a suggestion > where this should go? There does not seem to be a particular chapter > in the manual that deals with portability across compilers (probably > because one usually assumes that sticking to the Fortran standard is > sufficient for achieving portability). The best match might be the > chapter on compiler characteristics: >=20 > https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gfortran/Compiler-Characteristic= s.html Why not? Anyway if your patch is accepted, the doc for -Wextra has to be up= dated accordingly. >=20 >> With your patch what happens if check() is an external function? >=20 > Haven't tried, but I guess you would get a warning, since the compiler > cannot tell whether 'check' is pure (unless you have an explicit > interface block that contains the PURE attribute). Much ado about nothing? >=20 >> Your patch is focusing on pr85599 and ignore pr57160. >=20 > Well, yes. PR 57160 is somewhat related, but orthogonal. It concerns > essentially the same issue, namely short-circuiting with logical > expressions, but proposes a different solution (making > short-circuiting depend on the -ffrontend-optimize flag). I wouldn't > say that's unreasonable, but independent of that I might still want to > know that my code is not portable, thus a warning makes sense in any > case (IMHO). >=20 >=20 >> What to do with >>=20 >> if(x>0 .and. sort(x)<10.0*log(x)) =E2=80=A6 >>=20 >> which is not portable to compilers computing the two expressions? >=20 > That's one of the typical cases that the patch should be able to > handle. If 'sort' is impure, this should trigger a warning with the > patch. If it is pure, it doesn't matter whether the rhs of the .and. > operator is executed (since there are no side effects). Or am I > missing something? I meant =E2=80=98sqrt=E2=80=99 (changed behind my back by the stupid spell-= checker). >=20 > Cheers, > Janus >=20 >=20 > 2018-07-12 13:16 GMT+02:00 Dominique d'Humi=C3=A8res : >> Hi Janus, >>=20 >>> after the dust of the heated discussion around this PR has settled a >>> bit, here is another attempt to implement at least some basic warnings >>> about compiler-dependent behavior concerning the short-circuiting of >>> logical expressions. =E2=80=A6 >>=20 >> IMO your patch is missing the only point I agree with you on this issue,= i.e., >> the short-circuit evaluation and the related portability issues should be >> documented. >>=20 >> With your patch what happens if check() is an external function? >>=20 >> Your patch is focusing on pr85599 and ignore pr57160. >>=20 >> What to do with >>=20 >> if(x>0 .and. sort(x)<10.0*log(x)) =E2=80=A6 >>=20 >> which is not portable to compilers computing the two expressions? >>=20 >> Cheers, >>=20 >> Dominique >>=20