https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #65 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 10 Dec 2014, burnus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 > > --- Comment #64 from Tobias Burnus <burnus at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #63) > > Unfortunately for the testcase this doesn't allow moving the division at all > > and we are lucky that we have range information at all because of the > > fortran > > frontend casting 'n' to unsigned before dividing by it. > > If it helps and the semantic is preserved, there is no reason not to > completely change what tree code the Fortran FE generates for loops. The attached patch helps, but only sofar as enabling moving the division out one loop level - if you add another nest the entry condition on it will prevent moving the division further. > [I think one reason for the odd way tree code for loops is generated is: The > current code makes it simple to permit loops which are always run once, as > some > Fortran 66 compilers did. For instance, "DO i = 2, 1" would then be executed > once. (Such loops are not permitted in F66 - and some compilers executed them > once others zero times; since F77, such loops are permitted and executed zero > times. Unsurprisingly, some old code from the 60s relies on the execute once > feature.) > > g77 and some commercial compilers have a compile flag like "-f66", gfortran > hasn't and I don't think it ever will.] I wondered if DO i = 1, 1, 0 is valid (a step of zero). Note that DO i = 2, 1 wouldn't be executed once with the current generated code, only DO i = 1, 1 is, but with step == 0 it would divide by zero.