Doing
fexcept_t ex = 0;
fesetexceptflag(&ex, excepts);
has the effect of _clearing_ all the exceptions in excepts. Using
fesetexceptflag doesn't make this easier, because we would have to
record which exceptions were already raised. So just set the fflags
bits in the fcsr register directly.
- Include fenv.c and fma(3) symbols (which just use the FMADD
instruction).
- Note the .FN symbols in libm for the asm functions. The FN symbols
point at the function _descriptors_; the .FN symbols point at the
first instruction of the function.
XXX Unclear why we have the .FN symbols for asm functions but not for
C functions. I'm not sure we should be exporting them.
1. Need <math.h> for __HAVE_LONG_DOUBLE.
2. Need <machine/ieee.h> for struct ieee_ext_u &c.
3. EXT_FRACLBITS, not LDBL_MANL_SIZE.
PR lib/58245: hypotl is broken on ld128 ports
By this point in the logic, x can't be zero, so it's either positive
or negative.
The high word hx, however, can be zero, when x is a small positive
subnormal. This means x is a small positive subnormal, so if x > y
we are computing nextDown, and if x < y we are computing nextUp.
hx is a (signed 32-bit) integer, not a double floating-point number,
so it's a little silly to compare hx > 0.0. But that on its own
isn't enough to trigger the bug because all signed 32-bit integers
can be represented by double on all NetBSD architectures.
PR lib/58236
compat/sparc64/sparc/bsd.sparc.mk doesn't define LIBC_MACHINE_CPU,
only LIBC_MACHINE_ARCH, so when the compat build gets to this
conditional, LIBC_MACHINE_CPU is just MACHINE_CPU, i.e., sparc64.
Since there's no `sparc64el' or `sparc64hf-el' that we need to
canonicalize by MACHINE_ARCH -> MACHINE_CPU, just use
LIBC_MACHINE_ARCH here.
These are trivial subroutines, not symbol aliases, for separate
reasons:
- frexpf has a different ABI from frexp (float vs double argument)
- frexp is defined in libc, not libm, so although long double is the
same as double, frexpl can't be an alias in libm of a symbol
defined in libc
32-bit has binary64 long double, same as double; 64-bit has binary128
long double, which is implemented with a few more symbols in libm
(which should maybe be hidden internal symbols, but let's get this
diagnostic measure in the build working before we think about
possibly deleting private symbols).
While here, delete #ifdef to handle ns32k -- I don't think that's
gonna be relevant any time soon; in case you hadn't noticed, the
world has moved on from ns32k to vax by now.
PR 57881
Not sure if this'll work for all ports -- we might need to split it
up finer-grained by different m68k flavours -- but let's give it a
try and see what breaks.
This will reduce the risk of accidentally adding or deleting the
wrong symbols while fixing the aliases.
(This is all the architectures I have a build tree for handy; can add
other architectures like m68k later.)
STRONG_ALIAS copies the symbol size and type, so it avoids warnings
like this:
/home/riastradh/netbsd/10/obj.vax/tooldir/bin/../lib/gcc/vax--netbsdelf/10.5.0/../../../../vax--netbsdelf/bin/ld: warning: type and size of dynamic symbol `ldexpl' are not defined
We should arrange to just have LDBL_NBIT unconditionally defined in the
appropriate MD header file, and make LDBL_IMPLICIT_NBIT an alias for
LDBL_NBIT==0. But for now this will do.
Seems likely that there are other parts of libm which would benefit
from being defined unconditionally in terms of ieee_ext_u, with
ieee_ext_u as an alias for ieee_double_u, in this scenario. But I
haven't gone looking yet.
EXT_FRACBITS, the number of bits in the _binary encoding_ that stores
the trailing significand field, is never 113. In IEEE 754 binary128,
it is 112, even though there are 113 bits of precision in the set of
floating-point numbers -- the leading 1 bit is implicit in binary128.
So ld128 platforms like aarch64 and sparc64 were skipping the real
definition and just defining rintl as an alias for rint, which is
wrong.
In contrast, LDBL_MANT_DIG, the number of bits of precision in the set
of floating-point numbers (p, in IEEE 754 parlance), is 113 in IEEE 754
binary128. This is also the constant used in FreeBSD libm anyway. So
let's just use that instead of trying to translate it to our private
EXT_FRACBITS (not defined in FreeBSD) with a fencepos terror. And
delete the buggy rintl=rint alias.
PR lib/58054
riastradh