From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71689 invoked by alias); 28 Jun 2016 13:50:02 -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 71655 invoked by uid 89); 28 Jun 2016 13:50:01 -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=H*Ad:D*es, quality X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 28 Jun 2016 13:49:51 +0000 Received: by mail-wm0-f53.google.com with SMTP id a66so28875623wme.0 for ; Tue, 28 Jun 2016 06:49:50 -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=sjVrKTbIKutCGa/cK8fpP7jXhVKxi92GRrOILDqQ3LQ=; b=NcLPSXScgVhss9cWQcPup+a63bw7N0LqveH/wgzO2AGIGucDd4pRgDUeL79mvlWUzV GC167iaVlTVbedMZlx7sy468WKk/WTnRVCVbrUa1z/w4MipTMFyZ9Ex5zTLr+249SIAE seVLZ2jOEdvLANjNX6M3r8L4yvsQ0PXbbJKbWxkRC1HMaxzaNhL+piKk+C6LEYMIOhqi H5lCbX5TqpdObsv7ZaTSjdvIx8KQ+oQS0q9tVb1vPnLZV5eoF/IgNI4AruDKFjNPCshd wUOz3ITBnZuktRXabxijyiUVOoMjLAn91G2NDbT3CxfHueVR3mQFDMdQucalHuKuCGB9 IUiQ== X-Gm-Message-State: ALyK8tJnZG62xJWL1cC3FLxvytywbvhffnJFx8ZjxRLE/QPKFTnKtjnyo/MjCHTrKDo1apuZUMGqxTVT4vvJHg== X-Received: by 10.194.21.39 with SMTP id s7mr3311990wje.24.1467121788309; Tue, 28 Jun 2016 06:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.147.203 with HTTP; Tue, 28 Jun 2016 06:49:47 -0700 (PDT) In-Reply-To: <20160628121011.GD52409@kam.mff.cuni.cz> References: <6662B213-476B-4624-808D-2AC0DB33E152@lps.ens.fr> <20160628121011.GD52409@kam.mff.cuni.cz> From: Richard Biener Date: Tue, 28 Jun 2016 13:50:00 -0000 Message-ID: Subject: Re: Fortran loops To: Jan Hubicka Cc: =?UTF-8?Q?Dominique_d=27Humi=C3=A8res?= , "fortran@gcc.gnu.org" , williamclodius@gmail.com, ahirst@cedint.upm.es, mliska@suse.cz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00109.txt.bz2 On Tue, Jun 28, 2016 at 2:10 PM, Jan Hubicka wrote: >> IIRC this has already been discussed in the past (gfortran.dg/do_1.f90). >> The Fortran standard requires that the variable i is equal to array(2)+1= on the loop exit, which causes an overflow if array(2) is equal to huge(i). >> So the code is invalid when b(2) =3D huge(x), but I don=E2=80=99t see wh= y the overflow of the exit value should lead to an infinite loop. > > The reason why I ask (again as I just noticed - thanks for reminding :) i= s that > the C equivalent: > > for(i=3Dlow;i<=3Dhigh;i++) > ... body ... > > is a lot easier to compile, but it will loop infinitly when the upper bou= nd > happens to be INT_MAX. To avoid that Fortran FE expand the loop as: > > if (low { > i=3Dlow; > do { > ... body ... > if (i=3D=3Dhigh) > break; > i++ > } > while (1) > } > > This results in at least one extra compare and usually also extra registe= r needed. > If we could avoid this codegen based on fact that such loops are undefine= d, we would > get improvements in thight and deeply nested loops. I.e. in exchange2 ben= chmark. > > Martin implemented the C-style codegen and it does improve code quality. > If the fact that we produce the complex loop code above is just QOI, perh= aps > we can introduce a flag controlling this and turn into C-style loop expan= sion > by default when optimizing? > The do-3.f90 testcase tests some of those so it will need to be split into > valid loops and invalid loops. I guess it might be GCC on its own removing the exit test based on undefined-overflow and computing an upper bound on the iteration. So if the testcases are really invalid I suppose that at least with -Ofast the Fortran FE could avoid the extra check. But IIRC the issue appeared on valid loops as well. (that said - I've been here before) Richard. > Honza > >> Dominique >> > On Jun 27, 2016, at 6:56 PM, Jan Hubicka wrote: >> > >> > Hello, >> > I have a Fortran question. The following program loops infinitly when= compiled >> > with ifort -O0, while it does the expected number of iterations with g= fortran. >> > The issue is that we do produce quite ineffective code to deal with >> > side cases like this. >> > >> > is the program bellow valid and expected to terminate? If so I guess = we want >> > to have it as a testcase. >> > >> > Thanks, >> > Honza >> > >> > program test_program >> > integer(4) :: b(2), a(22), x >> > integer(8) :: suma >> > >> > b(1) =3D huge(x)-10 >> > b(2) =3D huge(x) >> > >> > call test2(b, suma) >> > print *,suma >> > >> > end program test_program >> > function test2(array, s) >> > integer(4) :: i, block(9), array(2) >> > integer (8) :: s >> > s =3D 1 >> > >> > do i =3D array(1), array(2) >> > s =3D s + 1 >> > end do >> > >> > end function test2 >> >