Walt Brainerd <[log in to unmask]>wrote: ... >I agree that the standard doesn't have the same words about >multi-statement >optimization, but we all know it "must be allowed". Otherwise, a >compiler >would not be free to move a statement out from the following loop (no >aliasing >among x, t, y and a, of course): > >do i = 1, n > x = cos (6.5*t) + y > a(i) = a(i) + x >end do Well, the "as-if" rule clearly applies. I doesn't matter to the meaning of the above whether X is computed once before the loop executes or whether you compute the expression every time. So, the result is indistinguishable (except for speed). It is generally held that, in such cases, the optimization is valid regardless of the apparent constraints of the language standard. Now, suppose it were the case that moving the evaluation of X outside the loop removed it from the numeric processor's stack, and that change reduces the precision to which X is stored. You could make the argument that such an optimization was invalid (the change would certainly no longer be covered by the "as-if" rule). Your complaint (in this case) would probably not be upheld since the standard doesn't guarantee any particular precision(!?). These are muddy waters. The purpose of parenthesis is to force evaluation order so that the user can insure numerical stability. The same could be said of Kurt Hirchert's example: T = B + C D = A * T In spite of that purpose though, the standard doesn't make any constraints on numerical accuracy. Vendors can (and sometimes do) defend optimizations (such as the loop invariant removal) as being valid: since you have no right to expect better precision than can be stored in the type of X anyway. But where's the dividing line? Somewhere between the level of parenthesis (which *do* force order) and the level of accepted optimizations (such as moving loop invariants) there is a gray area. I'm not even sure which side of the line Kurt Hirchert's example falls on. (In fact, I suspect that using the distributive law would be disallowed. I suspect that loss of precision - or extra precision - because of whether T were actually stored or not *would* be allowed.) This is not merely an academic exercise. I've heard that the work on interval arithmetic was held up on this very issue for some time. This is probably one of the reasons that interval arithmetic was dropped from the present cycle. It would probably be good to have this issue directly addressed (but who has the time?). -- J. Giles %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%