"Donsbach, Jeff" <[EMAIL PROTECTED]> writes:
> 98 times out of 100, Floating Point Exception errors on Alpha are caused
> by either an uninitialized floating point variable (that happens to have
> random garbage in it) being used in a calculation, or a floating point
> "divide by zero" operation. Those are plain and simple program bugs and
> using the IEEE compiler switches just masks the real problem.
>
> Jeff Donsbach
[EMAIL PROTECTED]:~% cat foo.cc
#include <iostream>
#include <cmath>
int main() {
double d = 1.0 + sqrt(-1.0);
}
[EMAIL PROTECTED]:~% g++ -o foo foo.cc
[EMAIL PROTECTED]:~% ./foo
zsh: floating point exception ./foo
[EMAIL PROTECTED]:~% g++ -mieee -o foo foo.cc
[EMAIL PROTECTED]:~% ./foo
[EMAIL PROTECTED]:~%
As you see there are more cases.
Suprisingly the problem is _not_ sqrt(-1.0) but the addition of 1.0
with NAN. Same goes for 1.0 + 1.0/0.0. 1.0/0.0 works perfect, just the
add fails.
On most (all?) other archs adding NAN to something just gives NAN and
you can thus calculate big formulas without checking every single
step. Saves a lot of time and code.
Another things are underruns or inexact traps, although I couldn't
shake an example out of my sleeves.
Sometimes its just so much easier to use "-mieee" and let the compiler
worry about the alpha specialities instead of searching all lines of
code if they need a #ifdef __alpha__.
May the Source be with you.
Goswin
PS: I consider an unitialised variable a BUG too, even warnings when
the compiler is wrong about it are ugly. Adding an extra "double d =
0.0;" where it isn't strictly needed doesn't hurt.
