Subject: Re: CCL:ifc -O0 failure

From: Serguei Patchkovskii <ps..at..ned.sims.nrc.ca>
Date: Mon, 9 Jun 2003 14:49:28 -0400 (EDT)

On Mon, 9 Jun 2003, caroline taylor wrote:

> -O0:    6.710886E+07  (21.960u 0.020s 0:22.19 99.0%)
> -O1:    1.718282E+08  (17.560u 0.010s 0:17.76 98.9%)

> The 0 level optimization is clearly inconsistent, and far larger than
> round off. This has been checked on multiple machines (all linux).
>
> Has anyone run into this before? Is there a known problem with this level,
> or is something else going on?

Caroline,

There is nothing wrong with ifc in this case - your program is badly
broken, and should not be relied upon to produce -any- definite
answer. You are trying to accumulate numbers, which deviate from
one in the 7-th decimal digit. However, you chose to use a type
(REAL), which is only accurate to 6-7 decimal digits. Obviously,
you should not expect to get any significant digits in the result.

With optimizations turned on, ifc carries the accumulation at
higher 80-bit precision (which is arguably allowed by the standard),
which -accidentally- leads to a result close to the mathematically
exact value.

If you change your SUM to DOUBLE PRECISION, you will get the answer of
171828183.705001 as an answer for ifc -O0 - which is reasonably close
to the formal result of 171828183.705045439197452888531281012...

Incidentally, if you try to use this loop for timing purposes, this
is not necessarily a good idea - a sufficiently smart compiler
could realise that the exact result is given by:

 (E - 1) E**(1/100000000)
 ------------------------
  E**(1/100000000) - 1

and completely eliminate the loop.

Serguei