Use of C99 extra long double math functions after r236148

[Bruce Evans]

On Mon, 23 Jul 2012, Peter Jeremy wrote:

> On 2012-Jul-22 22:12:19 +1000, Peter Jeremy <peter at server.rulingia.com> wrote:
>> A have simplified the default (NaN + I*NaN) return from catanh() to
>> the minimun to ensure that both real & imaginary parts return as NaN.
>> I've been doing some experiments on mixing NaNs using x87, SSE, SPARC64
>> and ARM (last on Linux) and have come to the conclusion that there is
>> no standard behaviour:  Given x & y as NaNs, (x+y) can return either
>> x or y, possibly with the sign bit from the other operand. depending
>> on the FPU.
>
> I've tried running my exception test program on Solaris/SPARC using
> SunStudio and it gives different results to FreeBSD/sparc64 in some
> cases so it looks like the FreeBSD/sparc64 exception handling code
> is also buggy.

It is certainly MD, but I think it should be fixed within an arch.  Not
vary with CFLAGS depending on optimizations and which register set is
selected, as happens on x86 due to the differences between x87 and SSE
and the compiler's choice of the register set.

For sparc64, 6 months ago before sparc64 switched from the old NetBSD(?)-
contribed emulation to soft-float, the emulation was just broken, and
I had to change parts of the library involving NaNs to get consistent
behaviour (fortunately, the bugs seem to be all in user space).  The
behaviour varied with -mhard-quad-float.  This option is not the default
for sparc64 because no known sparc64 implementation implements it in
hardware.  The hardware only implements the opcodes, and traps to emulate
them, while with soft-float the emulation uses similar code (but was
more broken for NaNs) without traps.  The traps just slow things down.
I used -mhard-quad-float a bit anyway because it is easier to debug.
In the disassembky it gives nice opcodes while soft-float gives large
code for libcalls, and gdb makes a mess of both stepping over the
libcalls if you don't want to see them (gdb steps into inline functions
when you don't want this) and of displaying them when you do want to
see them (display of register variables in inline functions is broken
on most arches, and the envionment for the sparc64 libcall and trap
code for emulation is especially challenging).

> And, when the base gcc tries to shortcut floating point expressions
> and execute them at compile time, it also gets exception handling
> wrong in several cases (it'll correctly detect that a constant
> expression evaluates to Inf or NaN but, in many cases, the NaN it
> calculates is different to the x87 or SSE evaluation of the same
> arguments).

Possibly invalid optimizations, but I've had good results from evaluating
1.0/0 and 0.0/0 at compile time.  gcc actually warns about these when
I really want these to be evaluated without side effects (exceptions).

Bruce