From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107741 invoked by alias); 24 Jul 2018 13:46:08 -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 107719 invoked by uid 89); 24 Jul 2018 13:46:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=seriously, H*Ad:D*ch, H*i:sk:D5E8D1C, H*f:sk:D5E8D1C X-HELO: mail-yw0-f171.google.com Received: from mail-yw0-f171.google.com (HELO mail-yw0-f171.google.com) (209.85.161.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Jul 2018 13:46:06 +0000 Received: by mail-yw0-f171.google.com with SMTP id e23-v6so1526642ywe.13; Tue, 24 Jul 2018 06:46:05 -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:content-transfer-encoding; bh=cliO2riG6fC7wxhQWsBq3Pvaac1nlwuaJqO0X2Yri5U=; b=hGVmy8VWmd2ojfqiJc00e0+tmmrEfl2ZnDBNENTPtXXNhBUiKrhEmcu7FmxGronmkt gH9fvBRzGkBAabTCD5efZiMfSHCCxZlMXEq7n9Atp6eUSfjkwsnsWwmDldzCQgwldtFl adttuhRYhdE6sCukqWj/8ZFiiFlua9Om0SUTLrxDzG19o5FIZ/APLHSCmLAEn5PpSjCa vQbhKmsZhaKcND1oM0phSOSacJheziHlA9FSI64UgK7cXeAl5DzpWNWPU4vi40P4g8IO lgIupsNoZYUJaK6yFyYKceth4nIxRqOm+e0eJaygFTOEcyk053QtpOESs4W+oxiNG5lg sZHQ== MIME-Version: 1.0 Sender: jaydub66@gmail.com Received: by 2002:a0d:ea0c:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 06:46:03 -0700 (PDT) In-Reply-To: References: From: Janus Weil Date: Tue, 24 Jul 2018 13:46:00 -0000 Message-ID: Subject: Re: [Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize To: =?UTF-8?Q?Dominique_d=27Humi=C3=A8res?= Cc: Adam Hirst , gfortran , gcc-patches , Joost.VandeVondele@mat.ethz.ch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00098.txt.bz2 2018-07-24 11:12 GMT+02:00 Dominique d'Humi=C3=A8res : > Hi Janus, > >> gfortran currently does short-circuiting, and after my patch for PR >> 85599 warns about cases where this might remove an impure function >> call (which potentially can change results). >> >> Now, this PR (57160) is about code which relies on the >> short-circuiting behavior. Since short-circuiting is not guaranteed by >> the standard, such code is invalid. Generating a warning or an error >> at compile-time is a bit harder here, though, since there are multiple >> variations of such a situation, e.g.: >> * ASSOCIATED(p) .AND. p%T >> * ALLOCATED(a) .AND. a%T >> * i> * =E2=80=A6 >> > > Aren=E2=80=99t you confusing portability with validity? I don' think so. > The above codes are indeed invalid without short-circuit evaluation, > but I did not find anything in the standard saying such codes are > invalid with short-circuit evaluation. If they're not valid without short-circuiting, then they're not valid at all, because the Fortran standard does not require a processor to do short-circuiting. >> The suggestion in the PR was to do short-circuiting only with >> optimization flags, but inhibit it with -O0, so that the faulty code >> will run into a segfault (or runtime error) at least when >> optimizations are disabled, and the problem can be identified. > > This PR has nothing to do with optimization and I think > it is a very bad idea to (ab)use any optimization option. The PR is definitely related to optimization, because the fact that the invalid test case works at all is only due to an optional optimization called short-circuiting. Don't get me wrong. I think it would be great if the Fortran standard would *require* short-circuiting for and/or operators (or had separate operators which do that). That would allow to write code like "ASSOCIATED(p) .AND. p%T" (which would actually be useful). Unfortunately that's not the case, therefore such code is plain invalid. > Please leave the default behavior (and test) as they are now. You seriously prefer to keep an invalid test case in the testsuite? > If you want non short-circuit evaluation, introduce an option for it. Your argument could easily be reversed: If you want short-circuiting, go introduce an option for it. I'm sure we'll not get anywhere this way, and I do think that Joost's suggestion to avoid short-circuiting with -O0 (and possibly -Og) is very reasonable: People who want maximum performance still get that with -O3, and at the same time they can still check their codes for errors with -O0. What is your problem?!? > Note that the warning introduce for pr85599 should be disabled > for non short-circuit evaluations. That's a valid point. Cheers, Janus