From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97020 invoked by alias); 28 Jun 2016 13:56:16 -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 97007 invoked by uid 89); 28 Jun 2016 13:56:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*Ad:D*es, quality X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 28 Jun 2016 13:56:05 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 6B07F545BF7; Tue, 28 Jun 2016 15:56:02 +0200 (CEST) Date: Tue, 28 Jun 2016 13:56:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , Dominique =?utf-8?Q?d'Humi=C3=A8res?= , "fortran@gcc.gnu.org" , williamclodius@gmail.com, ahirst@cedint.upm.es, mliska@suse.cz Subject: Re: Fortran loops Message-ID: <20160628135602.GB52343@kam.mff.cuni.cz> References: <6662B213-476B-4624-808D-2AC0DB33E152@lps.ens.fr> <20160628121011.GD52409@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2016-06/txt/msg00110.txt.bz2 > > 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, perhaps > > we can introduce a flag controlling this and turn into C-style loop expansion > > 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. It is explicitly testing loops that are unefined according to this discussion define TEST_LOOP(var,from,to,step,total,test,final) \ TEST_LOOP(i1, -huge(i1)-1_1, huge(i1), 1_1, int(huge(i1))*2+2, test_i1, huge(i1)+1_1) this is loop from INT_MIN to INT_MAX which can't be implemented in c-style manner without a wider type > > 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. I don't know of any other testcase than one above. I guess we could implement flag, default it for -Ofast and see what is the impact and consequently discuss O2/O3. Any suggestions for flag name? -ffast-do-loops? > (that said - I've been here before) Honza > > 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 gfortran. > >> > 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) = huge(x)-10 > >> > b(2) = 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 = 1 > >> > > >> > do i = array(1), array(2) > >> > s = s + 1 > >> > end do > >> > > >> > end function test2 > >> >