FPE handling

[olebole]

When compiling the following code on an x86_64 Linux platform (f.e. Debian Squeeze) from the original binary distribution:

File: fpe.x

task fpe = t_fpe
procedure t_fpe()
real    x, y, z
begin
    call eprintf ("Begin FPE Test ...\n")
    x = 1.0
    y = 0.0
    z = x / y
    call eprintf ("End FPE Test ...\n")
end

Instead of a floating point exception, one sees (even without optimization)

cl> xc -/O0 fpe.x
cl> task $fpe = fpe.e
cl> fpe
Begin FPE Test ...
End FPE Test ...

This shows, that in 2.16.1, the FPE handling is incorrect. No idea whether this shoud be fixed, however.

---

Ref: This is taken from the IRAF V2.14 announcement:

3.1.1 OPTIMIZATION CHANGES FOR MAC OS X

At some point in the OS X 10.4 upgrade cycle, the original changes made in the V2.13 release to the floating-point exception handling (which used to work) were being silently disabled. This was traced to a GCC compiler optimizer bug of some kind, meaning that IRAF code compiled with ANY level of optization would fail to trap any divide-by-zero, overflow, etc exceptions in the system. After a lengthy and detailed search, the exact file triggering this error has not been located.
As a result, the initial V2.14 release for Mac OSX systems (Intel and PPC) were compiled WITHOUT OPTIMIZATION. Benchmarks indicate this penalizes the performance of code by only about 6% in overall usage, less depending on the specific task.
It was felt that the ability to properly trap errors and produce correct results was more important than saving typically a second or two during normal processing. The default compiler flags for this platform have been set so that outside developers or users compiling locally will likewise produce the correct error-trapping code.
An example program one can use to see whether FPE handling is working properly would be something like:

task fpe = t_fpe

procedure t_fpe()
real    x, y, z
begin
    call eprintf ("Begin FPE Test ...\n")
    x = 1.0
    y = 0.0
    z = x / y
    call eprintf ("End FPE Test ...\n")
end

This can be compiled as

% xc fpe.x			# no optimization (default)
% xc -/O3 fpe.x			# compiled w/ optimization

Note however that the second example will execute to completion rather than stop with the expected "floating point divide by zero" message. The value of the 'z' variable is undefined, and the task may appear "hang" in some instances. Users are STRONGLY DISCOURAGED from changing
the optimization level on their own until this problem is better understood.