------- Comment #14 from rguenth at gcc dot gnu dot org 2009-11-20 23:48 ------- (In reply to comment #13) > > The funny conditional initialization of countm1.6 makes the analysis of > > the number of iterations of this loop impossible (not to mention the > > conversions to character(kind=4)). > > > Why does the frontend do induction variable "optimization" at all and > > not simply generate a loop with a non-unit counting IV? > > It's not trying to be funny - it just follows the text of the Fortran Standard > (hey, what a concept !): > > 12 8.1.6.6.1 Loop initiation > 13 1 When the DO statement is executed, the DO construct becomes active. If > loop-control is > 14 2 [ , ] do-variable = scalar-int-expr 1 , scalar-int-expr 2 [ , > scalar-int-expr 3 ] > 15 3 the following steps are performed in sequence. > 16 (1) The initial parameter m1 , the terminal parameter m2 , and > the incrementation parameter m3 are > 17 of type integer with the same kind type parameter as the > do-variable. Their values are established > 18 by evaluating scalar-int-expr 1 , scalar-int-expr 2 , and > scalar-int-expr 3 , respectively, including, if ne- > 19 cessary, conversion to the kind type parameter of the > do-variable according to the rules for numeric > 20 conversion (Table 7.11). If scalar-int-expr 3 does not > appear, m3 has the value 1. The value of m3 > 21 shall not be zero. > 22 (2) The DO variable becomes defined with the value of the > initial parameter m1 . > 23 (3) The iteration count is established and is the value of the > expression (m2 - m1 + m3 )/m3 , unless that > 24 value is negative, in which case the iteration count is 0. > > Only interprocedural analysis can tell us that this is a simple loop only > executed 3 times (I got this wrong at first - it's *always* executed 3 times).
I don't see that the standard suggests the specific code the Frontend generates. In fact it should be valid to increment the DO variable by m3 and express the exit test in terms of the DO variable as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
