From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101749 invoked by alias); 30 Jun 2016 11:43:48 -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 101718 invoked by uid 89); 30 Jun 2016 11:43:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1619, H*Ad:D*es X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 30 Jun 2016 11:43:37 +0000 Received: by mail-wm0-f47.google.com with SMTP id a66so114560967wme.0 for ; Thu, 30 Jun 2016 04:43:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vDYR6e0h97D7BnbwXez4mLHYiRGhSTlN4AKV7IAVu3k=; b=JLbGA+M1N4QvHa5Kb1qbbe8ZBfjPiFhPDS82oKFiu7gODDR5F4mDrnDetGwbPKsewz ebJnc5CyCmKBleIp/cu6WQu/8uSyrmXjRWuW0OMaxNmKgNX+i+gjWQaJ6BfXPJ1Z1aa3 ZHyON1TpYqIOmAEmSoIkKgDMeBBih9KIXJhcEDLlbbMuH0PeJcXHYtfJbHYnIi4oPI3i /CJKTmkqs0JiFZ4uEHbPItCj16FnCpnGkIB1w2c7ECr2P94q6pjsNAnbp00O8CBkzIAH 6RWKEUmXbUp/OveTnvhIoccQ/moo2LfAJK0LVPFRocSlmGu+33BbPj09IyEKtPfV5Sf6 8Pdg== X-Gm-Message-State: ALyK8tJN4KukuDDEpYMH0iY210UufVSnmc8HWWyh9XEJ/UwH80HrTMM+Dsd9+lr7kN9p0jrh0F7bvFHK3Ldq+A== X-Received: by 10.28.147.7 with SMTP id v7mr13541452wmd.37.1467287014621; Thu, 30 Jun 2016 04:43:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.147.203 with HTTP; Thu, 30 Jun 2016 04:43:34 -0700 (PDT) In-Reply-To: <60bcb1f6-ff54-95ac-d69d-966542a8aaa9@suse.cz> References: <6662B213-476B-4624-808D-2AC0DB33E152@lps.ens.fr> <20160628121011.GD52409@kam.mff.cuni.cz> <20160628135602.GB52343@kam.mff.cuni.cz> <60bcb1f6-ff54-95ac-d69d-966542a8aaa9@suse.cz> From: Richard Biener Date: Thu, 30 Jun 2016 11:43:00 -0000 Message-ID: Subject: Re: [PATCH, RFC] Introduce -ffast-do-loop flag. To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Jan Hubicka , =?UTF-8?Q?Dominique_d=27Humi=C3=A8res?= , "fortran@gcc.gnu.org" , williamclodius@gmail.com, ahirst@cedint.upm.es Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00123.txt.bz2 On Thu, Jun 30, 2016 at 1:16 PM, Martin Li=C5=A1ka wrote: > Hello. > > This is patch attempt to target the discussion about sub-optimal generati= on > of DO loops with abs(step) =3D=3D 1. > > Originally generated code: > > D.3428 =3D (*array)[0]; > D.3429 =3D (*array)[1]; > i =3D D.3428; > if (i <=3D D.3429) > { > while (1) > { > { > logical(kind=3D4) D.3432; > > (*block)[(integer(kind=3D8)) i + -1] =3D (*block)[(integer(= kind=3D8)) i + -1] + 10; > L.1:; > D.3432 =3D i =3D=3D D.3429; > i =3D i + 1; > if (D.3432) goto L.2; > } > } > } > L.2:; > > Suggested: > > D.3428 =3D (*array)[0]; > D.3429 =3D (*array)[1]; > i =3D D.3428; > while (1) > { > { > logical(kind=3D4) D.3432; > > D.3432 =3D i > D.3429; > if (D.3432) goto L.2; > (*block)[(integer(kind=3D8)) i + -1] =3D (*block)[(integer(kind= =3D8)) i + -1] + 10; > L.1:; > i =3D i + 1; > } > } > L.2:; > > I would like to enable the behavior be default, patch does that starting = from -O2. > > Apart from that, I've also added a new warning (candidate name: Wundefine= d-do-loop), which warns about cases that > would lead to an infinite loop (because i > HUGE(i) =3D=3D false): > > Warning: DO loop at (1) is infinite as it iterates to MIN_INT [-Wundefine= d-do-loop] > /tmp/loop2.f90:15:19: > > do i =3D 0, huge(i) > 1 > > Patch hasn't been properly tested, I've just tried to run all do_*.[fF]90= tests. > > Thoughts? Without looking at the patch I think if there is some -fcheck option for the boundary case and the behavior is really undefined for end =3D=3D HUGE() then having the default independent of optimization level would be nice. Richard. > Martin >