newterm() argument is const in the spec, so this fixes our
conformance.
setterm() is not in the spec, but it's natural and in ncurses its
argument is const too, so follow suit.
Doesn't change the ABI, so no bump required.
ok blymn@
callback because el_line updates the legacy LineInfo structure and
we need to notify that the cached copy of the the buffer has changed.
Of course the resizing function can call el_line itself to update
the buffer, so prevent recursion. Bug found by Peter Rufer at Arista.
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
This reverts:
hdtoa.c 1.12 (PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core)
hdtoa.c 1.11 (fix tyop)
hdtoa.c 1.10 (Via enh at google dot com in tech-userlevel. Fix handling of
EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).)
The underlying motivation for this change was that when ld128 is
decomposed into 4x32 words, this hldtoa logic is broken.
But we don't decompose ld128 into 4x32 words; we decompose it into
6x64 words.
And the change, which was supposed to be a noop in our case of 2x64
words (or similar for x87 80-bit floating-point), broke it to the
point of causing buffer overruns (PR 56247) which when worked around
led to just incorrect output output (PR 56937).
If we want to make the #ifdefs for 4x32 words work, that's fine, but
we absolutely must have automatic test cases to detect this kind of
regression because %La formatting is extremely important for
diagnosing details of floating-point data since it doesn't involve
rounding in binary formats. For now I've added some trivial tests;
there is a more extensive test suite inside gdtoa that we need to
wire up before anyone tries any other shenanigans in this code.
PR lib/56937: printf(3) long double %a formatting is broken
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.
skrll