As reported on PR34702 I stumbled over expressions such as IF ( FLOAT(NNP/NP).EQ.FLOAT(NNP)/XNP ) THEN or IF (RADIUS>=X(N)/100.0 .AND. RADIUS<=X(N+1)/100.0) EXIT which can obviously be rearranged as IF (XNP* FLOAT(NNP).EQ.FLOAT(NP*NNP) ) THEN or IF (100.0*RADIUS>=X(N) .AND. 100.0*RADIUS<=X(N+1)) EXIT The first change overcome the problem in PR34702 with aermod.f90 and -mrecip, while the second gives some speed up to gas_dyn.f90 (for large numbers of iterations: 13% for 200000 iterations). Such optimizations are indeed assuming that there is no overflow (-ffinite-math-only?) and that the code is not relying on side effects due to the division round-off (-funsafe-math-optimizations?). Would such an optimization make sense and be difficult to implement (with the appropriate option(s), e.g., one or both of the above)?
-ffinite-math-only is not enoug - that only assumes input operands are never Inf or Nan and results of operations in the source are not Inf or Nan. But as you say you cannot guarantee that RADIUS * 100.0 does not overflow, so this transformation is invalid.