soft-fp should round floating pointer numbers according to the current
rounding mode. However, in the current code of lrint() and llrint(),
there are if statements before the actual rounding computation
if(j0 < -1)
return 0;
Where j0 is the exponent of the floating point number.
It means any number having a exponent less than -1
(i.e. interval (-0.5, 0.5)) will be rounded to 0 regardeless of the
rounding mode.
The bug already fixed in glibc in 2006 by moving the check afterwards
the rounding computation, but still persists in newlib.
This patch fixed it in a similar way to glibc
Ref Commit in glibc: 6624dbc07b5a9fb316ed188ef01f65b8eea8b47c
Zfinx/Zdinx are new extensions ratified in 2022, it similar to F/D extensions,
support hard float operation for single/double precision, but the difference
between Zfinx/Zdinx and F/D is Zfinx/Zdinx is operating under general purpose
registers rather than dedicated floating-point registers.
This patch improve the hard float support detection for RISC-V port, so
that Zfinx/Zdinx can have better/right performance.
Co-authored-by: Jesse Huang <jesse.huang@sifive.com>
Rename s_nearbyint.c, s_fdim.c and s_scalbln.c to remove conflicts
Remove functions that are not needed from above files
Modify include paths
Add includes missing in cygwin build
Add missing types
Create Makefiles
Create header files to resolve dependencies between directories
Modify some instances of unsigned long to uint64_t for 32 bit platforms
Add HAVE_FPMATH_H
E.g. known errors:
x = 0x1.000002c5e2e99p+0, y = 0x1.c9eee35374af6p+31 had an error of 639
ULP and is now correctly rounded.
x = 0x1.fffffd2e3e669p-1, y = 0x1.344c9823eb66cp+32 had an error of 428
ULP and is now correctly rounded.
This implements a set of vectorized math routines to be used by the
compiler auto-vectorizer. Versions for vectors with 2 lanes up to
64 lanes (in powers of 2) are provided.
These routines are based on the scalar versions of the math routines in
libm/common, libm/math and libm/mathfp. They make extensive use of the GCC
C vector extensions and GCN-specific builtins in GCC.
The implementation of expf() explains how approximation in the range [0 - 0.34] is done. The comment describes the "Reme" algorithm for constructing the polynomial. This is a typo and should be the "Remez" algorithm. The remez algorithm (or minimax) is used to calculate the coefficients of polynomials in other implementations of exp(0 and log().
See more:
https://en.wikipedia.org/wiki/Remez_algorithm
This implements a set of vectorized math routines to be used by the
compiler auto-vectorizer. Versions for vectors with 2 lanes up to
64 lanes (in powers of 2) are provided.
These routines are based on the scalar versions of the math routines in
libm/common, libm/math and libm/mathfp. They make extensive use of the GCC
C vector extensions and GCN-specific builtins in GCC.
By default, Newlib uses a huge object of type struct _reent to store
thread-specific data. This object is returned by __getreent() if the
__DYNAMIC_REENT__ Newlib configuration option is defined.
The reentrancy structure contains for example errno and the standard input,
output, and error file streams. This means that if an application only uses
errno it has a dependency on the file stream support even if it does not use
it. This is an issue for lower end targets and applications which need to
qualify the software according to safety standards (for example ECSS-E-ST-40C,
ECSS-Q-ST-80C, IEC 61508, ISO 26262, DO-178, DO-330, DO-333).
If the new _REENT_THREAD_LOCAL configuration option is enabled, then struct
_reent is replaced by dedicated thread-local objects for each struct _reent
member. The thread-local objects are defined in translation units which use
the corresponding object.
Unless make is invoked with V=1, have xmlto pass the parameter
'man.output.quietly=1' to xsltproc to suppress "Note: Writing foo.N"
output from the manpages stylesheet.
(This doesn't quite do what it says: The output is not silenced if V has
any value, including 0. You could consider that either a bug or a
feature.)
Simplify rules for creating docbook XML used to create manpages:
Updating the output using move-if-change and then unconditionally
touching the .stamp file doesn't make much sense.
Integrate the old libm/test/ subdir into the main build. It hasn't
been used in a long time causing the code to rot a bit. I've fixed
some of those, but it still fails for many ports, so it's disabled
by default. People who want to take a closer look can run:
$ make libm/test/test
Convert all the libm/ subdir makes into the top-level Makefile. This
allows us to build all of libm from the top Makefile without using any
recursive make calls. This is faster and avoids the funky lib.a logic
where we unpack subdir archives to repack into a single libm.a. The
machine override logic is maintained though by way of Makefile include
ordering, and source file accumulation in libm_a_SOURCES.
One thing to note is that this will require GNU Make because of:
libm_a_CFLAGS = ... $(libm_a_CFLAGS_$(subst /,_,$(@D)))
This was the only way I could find to supporting per-dir compiler
settings, and I couldn't find a POSIX compatible way of transforming
the variable content. I don't think this is a big deal as other
Makefiles in the tree are using GNU Make-specific syntax, but I call
this out as it's the only one so far in the new automake code that
I've been writing.
Automake doesn't provide precise control over the output object names
(by design). This is fine by default as we get consistent names in all
the subdirs: libm_a-<source>.o. But this relies on using the same set
of compiler flags for all objects. We currently compile libm/common/
with different optimizations than the rest.
If we want to compile objects differently, we can create an intermediate
archive with the subset of objects with unique flags, and then add those
objects to the main archive. But Automake will use a different prefix
for the objects, and thus we can't rely on ordering to override.
But if we leverage $@, we can turn Automake's CFLAGS into a multiplex
on a per-dir (and even per-file if we wanted) basis. Unfortunately,
since $@ contains /, Automake complains it's an invalid name. While
GNU Make supports this, it's a POSIX extension, so Automake flags it.
Using $(subst) avoids the Automake warning to get a POSIX compliant
name, albeit with a GNU Make extension.
Commit 8fa73a9f84 changed how fenv.c is
compiled wrt mips16 targets used the wrong variable to add fenv.o to
libm.a. Fix that thinko so it's included in the build again.
This is used in a bunch of places, but nowhere is it ever set, and
nowhere can I find any documentation, nor can I find any other project
using it. So delete the flags to simplify.
The original cut for small arguments at |x|<2**-70 (copied from the
double version) produces that when computing nadj we get a subnormal
number for t*x and thus, the division of pi/subnormal will be INF and
the logarithm of it too, which is wrong as a result for lgammaf in this
range.
The proposed new limit seems to be safe and has been tested to
produce accurate results.
(Courtesy of Andreas Jung, ESA)
These look like they were just copied & pasted from common/Makefile.am.
The funcs in this dir are all stubs that don't actually call any math
or builtin functions, and a simple compile shows they produce identical
object code. So delete to simplify the build rules.
Correct the overflow limit in the variable o_threshold to be consistent
with the FLT_UWORD_LOG_MAX variable used by the internal implementation
of the expf algorithm itself.
The u_threshold variable has also been modified to be written in the
same format.
Note that this fix improves the situation but does not completely
correct the inconsistencies regarding the overflow and underflow limits
between the expf wrapper (wf_exp.c) and the expf algorithm itself
(ef_exp.c).
Currently these limits are different for the
_FLT_LARGEST_EXPONENT_IS_NORMAL and _FLT_NO_DENORMALS cases as well as
for the case where __OBSOLETE_MATH is not defined (only for the
underflow limit in this case).
This kills off the last configure script under libm/ and folds it
into the top newlib configure script. The vast majority of logic
was already in the top configure script, so move the little that
is left into a libm/acinclude.m4 file.
Make sure we depend on the right name of mkdoc all the time, and that
the rules that need it (e.g. .def files) depend on it.
Reported-by: Jon Turney <jon.turney@dronecode.org.uk>
This was only ever used for i?86-pc-linux-gnu targets, but that's been
broken for years, and has since been dropped. So clean this up too.
This also deletes the funky objectlist logic since it only existed for
the libtool libraries. Since it was the only thing left in the small
Makefile.shared file, we can punt that too.
Now that we use AC_NO_EXECUTABLES, and we require a recent version of
autoconf, we don't need to define our own copies of these macros. So
switch to the standard AC_PROG_CC.
This logic was added to libc & libm to get it working again after some
reworks in the CPP handling, but now that that's settled, let's move
this to the common newlib configure logic. This will make it easier
to consolidate all the configure calls into the top-level newlib dir.
This does create a lot of noise in the generate scripts, but that's
because of the ordering of the calls, not because of correctness. We
will try to draw that back down in follow up commits as we modernize
the toolchain calls in here.
This code is a bit more convoluted than it needs to be. GPR_SOURCES
is never set to anything, and the automake checks use negative logic
to add the SP & DP source files to dedicated variables that are only
expanded once. Get rid of the unused variable, use normal boolean
logic, and collapse the source settings into a single variable.
This allows building the libc & libm pages in parallel, and drops
the duplication in the subdirs with the chew/chapter settings.
The unused rules in Makefile.shared are left in place to minimize
noise in the change.
This isn't strictly necessary, but it makes for much clearer logs as
to what the target is doing, and provides cache vars for anyone who
wants to force the test a different way, and it lets the build cache
its own results when rerunning config.status.
Restore the call to AC_NO_EXECUTABLES -- I naively assumed in commit
2e9aa5f56c ("newlib: update preprocessor
configure checks") that checking for a preprocessor would not involve
linking code. Unfortunately, autoconf will implicitly check that the
compiler "works" before allowing it to be used, and that involves a
link test, and that fails because newlib provides the C library which
is needed to pass a link test.
There is some code in NEWLIB_CONFIGURE specifically to help mitigate
these, but it's not kicking in here for some reason, so let's just add
the AC_NO_EXECUTABLES call back until we can unwind that custom logic.
Additionally, we have to call AC_PROG_CPP explicitly. This was being
invoked later on, but only in the use_libtool=yes codepath, and that
is almost never enabled.
When we had configure scripts in subdirs, the newlib_basedir value
was computed relative to that, and it'd be the same when used in the
Makefile in the same dir. With many subdir configure scripts removed,
the top-level configure & Makefile can't use the same relative path.
So switch the subdir Makefiles over to abs_newlib_basedir when they
use -I to find source headers.
Do this for all subdirs, even ones with configure scripts and where
newlib_basedir works. This makes the code consistent, and avoids
surprises if the configure script is ever removed in the future as
part of merging to the higher level.
Some of the subdirs were using -I$(newlib_basedir)/../newlib/ for
some reason. Collapse those too since newlib_basedir points to the
newlib source tree already.
When using the top-level configure script but subdir Makefiles, the
newlib_basedir value gets a bit out of sync: it's relative to where
configure lives, not where the Makefile lives. Move the abs setting
from the top-level configure script into acinclude.m4 so we can rely
on it being available everywhere. Although this commit doesn't use
it anywhere, just lays the groundwork.
The machine configure scripts are all effectively stub scripts that
pass the higher level options to its own makefile. The only one doing
any custom tests was nds32. The rest were all effectively the same as
the libm/ configure script.
So instead of recursively running configure in all of these subdirs,
generate their makefiles from the top-level configure. For nds32,
deploy a pattern of including subdir logic via m4:
m4_include([machine/nds32/acinclude.m4])
Even its set of checks are very small -- it does 2 preprocessor tests
and sets up 2 makefile conditionals.
Some of the generated machine makefiles have a bunch of extra stuff
added to them, but that's because they were inconsistent in their
configure libtool calls. The top-level has it, so it exports some
new vars to the ones that weren't already.
The machine/{configure,Makefile} files exist only to fan out to the
specific machine/$arch/ subdir. We already have all that same info
in the libm/ dir itself, so by moving the recursive configure and
make calls into it, we can cut off this logic entirely and save the
overhead.
For arches that don't have a machine subdir, it means they can skip
the logic entirely.
Alexey Lapshin
Jesse Huang via Newlib
Jennifer Averett
Andoni Arregi
Tobias Burnus
Kwok Cheung Yeung
Jeff Johnston
Nadav Rotem
Matt Joyce
Jon Turney
Mike Frysinger