[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: aptitude on alpha (again, sigh)




  Goswin Brederlow wrote:
> 
> mrvn@alpha:~% cat foo.cc       
> #include <iostream>
> #include <cmath>
> 
> int main() {
>         double d = 1.0 + sqrt(-1.0);
> }
> mrvn@alpha:~% g++ -o foo foo.cc
> mrvn@alpha:~% ./foo            
> zsh: floating point exception  ./foo
> mrvn@alpha:~% g++ -mieee -o foo foo.cc
> mrvn@alpha:~% ./foo                   
> mrvn@alpha:~% 
> 
> As you see there are more cases.
.
.
.

Oh, I am not saying there aren't. And in this case, the use of the
-mieee switch could be perfectly appropriate depending on the real app.
What I am saying is that in the vast majority of cases where I've seen
people use IEEE compiler flags on a program, there really was no reason
to. It was mostly being used because of uninitialized variable bugs and
the people were too lazy to find what the real problem was.

Folks should also realize that use of IEEE flags can have negative
performance implications. Floating point traps on most Alpha
implementations (pre-EV6 anyway) are not synchronous. One of the things
the ieee switches do is to tell the compiler to insert TRAPB
instructions after almost every floating point instruction. This
effectively stalls the CPU to wait until the floating point op has made
it through the pipeline so that any exceptions can be handled
synchronously. See why it can kill performance? I'm pretty sure that on
EV6 and later, TRAPB instructions are effectively treated as NOOP
instructions, so the performance hit isn't as substantial. But there is
still the penalty of trapping to special exception handlers to deal with
the exception.

The moral of the story is if you are going to use -mieee, know why you
are using it and not just to fix a crash where you haven't investigated
what the real problem is.

Jeff Donsbach





Reply to: