sqrt on alphaev6

[Brad Lucier]

Toon Moene wrote:

> Brad Lucier wrote:
> 
> > with -mcpu=ev6 -mieee on alphaev6 with gcc 2.95.1 the following code
> > is typically generated for sqrt:
> 
> >         sqrttsu $f16,$f0
> >         cmpteqsu $f0,$f0,$f10      ; check for NaN?
> >         fbne $f10,$L836
> >         jsr $26,sqrt
> >         ldgp $29,0($26)
> > $L836:
> 
> > My question is whether the call to the sqrt routines is necessary
> > for ev6.  I find 21264hrm.pdf to be somewhat confusing, but it
> > seems to imply that software completion is not needed on the 21264.
> 
> According to the documentation accompanying gcc, one can specify the
> following macro name for any target architecture (cpu/os combination):
> 
> `TARGET_EDOM'
>      The value of `EDOM' on the target machine, as a C integer constant
>      expression.  If you don't define this macro, GNU CC does not
>      attempt to deposit the value of `EDOM' into `errno' directly.
>      Look in `/usr/include/errno.h' to find the value of `EDOM' on your
>      system.
> 
...
> 
> This constant is not defined for many targets:
...

Geoff Keating wrote:

> On most targets (certainly all linux, for instance), you can't do this because
> the math error handling is more complicated than just setting errno.
> 
> SVR4-derived code expects an application function called 'matherr' to
> be called, for instance (yuk!).

I think this is another IEEE arithmetic issue.  I've just looked through
the draft ISO C standard (with header [ISO/] [IEC] JTC1/SC22/WG14
N843) and it seems to say that error handling for sqrt should follow
the IEEE arithmetic standard.  Although I can't quite work through
/usr/include/math.h in my linux distribution, it seems to imply that
IEEE error handling is sometimes an option.

So, if gcc with -mieee is not going to set EDOM for 1.0/0.0, but either
(a) set the result to infinity and continue or (b) halt the program with
a trap, depending on how the IEEE trap handler is set, then sqrt(-1.0)
should do the same thing, depending on precisely the same trap handler.

Brad Lucier    lucier@math.purdue.edu