> > > In effect, optimizations which are not detectable
> > > with something like PRINT statements are OK.
>
> So, Dick, can you get J3 to officially get back to this position???
Sounds like a good idea.
> > As in a feature John Appleyard has just reported on c.l.f where
> > an aggresive optimiser removed all the code from a program which
> > did not contain any IO statements !
Actually, I think there would be more cause for complaint if the
optimiser DIDN'T remove all the code in this case. This extreme example
is the exception which proves the rule (in the original sense of the
phrase).
> I often disagree with this sort of statement in a different
> context 8^), but it certainly is right on for this situation.
I agree.
> Does anybody think a compiler should not be allowed to do
> the kinds of optimizations we have been talking about:
> moving invariant code out of loops, removing "dead" code,
> inlining procedures, combining expressions in more than
> one statement (Interp #1?) etc?
No. To get back to the original thread, the parentheses priority needs
to be addressed in a backward-compatible way, but otherwise it should be
allowed.
And yes, it should remove all the code if there is no I/O. The compiler
cannot be expected to guess whether the user is trying to run a
benchmark. Any benchmark can add some code with a calculable overhead
to make the final, output result depend on all the code; calling a RNG
would be a good example. Of course, don't do
J = 0
DO, I = 1, 10000000000, 1 ! here, I miss nonsignificant blanks
<essentially dead code>
J = J + 1
END DO
PRINT*, J
as it could be calculated at compile time! :-)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|