Re: aptitude on alpha (again, sigh)

[Stefan Schroepfer <whoknows@onlinehome.de>]

Goswin Brederlow wrote:
> "Donsbach, Jeff" <Jeff.Donsbach@compaq.com> 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
>>
>
> mrvn@alpha:~% cat foo.cc
> #include <iostream>
> #include <cmath>
>
> int main() {
>         double d = 1.0 + sqrt(-1.0);
> }
> [...]
>
> 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.

But one could still argue that the possibility
of a call to sqrt () with a negative argument
and a possible division by zero essentially *are*
coding bugs.
Alpha behaviour isn't that bad in all cases as it
points you to somewhere in the code shortly after
the real problem.

> 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.

And probably leads to useless results (wouldn't the
cause for this have to be hunted down anyways)?

> 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__.

O.k., maybe sometimes. But I learned to like the
more stringent Alpha floating point behaviour
without using a IEEE switch.


Regards,
Stefan Schroepfer