From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16143 invoked by alias); 16 Jul 2018 08:07:04 -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 5386 invoked by uid 89); 16 Jul 2018 08:06:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=HX-Received:Mon, H*f:sk:de6df17, H*i:sk:de6df17, throwing X-HELO: mail-yb0-f176.google.com Received: from mail-yb0-f176.google.com (HELO mail-yb0-f176.google.com) (209.85.213.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Jul 2018 08:06:54 +0000 Received: by mail-yb0-f176.google.com with SMTP id y11-v6so15090540ybm.7; Mon, 16 Jul 2018 01:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=J+cw50tMqb2V9sK2Cj9pIl7rtHpYPyCWMo+a46bntPU=; b=rjT8G5ADEZY2xXEasfs9J/wLwUsxFGEmT7VtdjxXIcg6ofgMUh+sHi639aZYn/UbjZ Xl+3IPcPA8CIqZ7kaxkvqt2mBie2rQ0ODeiTHDRlMfopncJpjwg2Ol5xsUN3oE87LSkI AbpvlgM2RfcortYfTQjmbiQ/EzE2BNrom8iJ6RGe6doM8wcuDFVHjkEGzlg/maeMuuIq 5bguQrks/JN54QjBy2UhZVmdBpwpapK7q6V2XflIxU2B7y/G+MSSPl1joZ+CHYCrTjaz rKZ0UDxSZevkTKvIg2T+uIKEJvePPV/qI9TCzrOJUpFPsB4r1K7gVqOfTvzyWx/Spmug NKTg== MIME-Version: 1.0 Sender: jaydub66@gmail.com Received: by 2002:a0d:ea0c:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 01:06:51 -0700 (PDT) In-Reply-To: References: From: Janus Weil Date: Mon, 16 Jul 2018 08:07:00 -0000 Message-ID: Subject: Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions To: Thomas Koenig Cc: gfortran , gcc-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00046.txt.bz2 Hi Thomas, >> I tested it on a fairly large code base and found no further false >> positives. Also it still regtests cleanly. Ok for trunk? > > > while I still disagree with this on principle, I will not stand > in the way. IIUC you disagree in the sense that you would like gfortran to have more such optimizations (with more corresponding warnings). Is that correct? I hope you can at least agree that the warnings I'm adding in the patch are a) useful and b) sufficient for the current state of optimizations? Modifying gfortran's runtime behavior is really a separate question that we can continue to discuss later, probably with some amount of controversy. But before we even go there, I would really like to have warnings for the optimizations we have now ... > However, one point: I think that the warning should be under a separate > warning, which should then be enabled by -Wextra. > -Waggressive-function-elimination, could be reused for this, > or something else I don't actually see such a flag in the manual. I do see "-faggressive-function-elimination" (https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html), but that is about changing runtime behavior, not about throwing warnings. Do you propose to couple the warning to -faggressive-function-elimination (and also the short-circuiting behavior itself)? Or do you propose to add a flag named -Waggressive-function-elimination? Cheers, Janus