NetBSD's rev 1.6 of this file, on !defined(SOFTFLOAT_FOR_GCC). These
functions are provided by libgcc, so we don't need them. This should
unbreak mips.
original vendor, but we're using their heavily modified version.)
This brings in functions for long double emulation (both extended and
quad formats), which may be useful for testing, and also for replacing
libc/sparc64/fpu/.
their implementations aren't in the same files. Introduce LIBC_ARCH
and use that in preference to MACHINE_CPUARCH. Tested by amd64 and
powerpc64 builds (thanks nathanw@)
rounding (impl. dep. #55), the SPARC JPS1 responsible for SPARC64 and
UltraSPARC processors defines that in all cases tininess is detected
before rounding therefore rounding up to the smallest normalized number
should set the underflow flag. This change is needed for using SoftFloat
on sparc64 for reference purposes.
PR: 144900
Submitted by: Peter Jeremy
to mistakes from day 1, it has always had semantics inconsistent with
SVR4 and its successors. In particular, given argument M:
- On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags
and *sets* the new flag word to M. (NetBSD, too?)
- On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M
and leaves the remaining flags unchanged (modulo a small bug on amd64.)
- On FreeBSD/ia64, it is not implemented.
There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps
and apps ported from other operating systems, so the best approach
seems to be to kill the function and fix any apps that break. I
couldn't find any ports that use it, and any such ports would already
be broken on FreeBSD/ia64 and Linux anyway.
By the way, the routine has always been undocumented in FreeBSD,
except for an MLINK to a manpage that doesn't describe it. This
manpage has stated since 5.3-RELEASE that the functions it describes
are deprecated, so that must mean that functions that it is *supposed*
to describe but doesn't are even *more* deprecated. ;-)
Note that fpresetsticky() has been retained on FreeBSD/i386. As far
as I can tell, no other operating systems or ports of FreeBSD
implement it, so there's nothing for it to be inconsistent with.
PR: 75862
Suggested by: bde
