Commit Graph

451 Commits

Author SHA1 Message Date
Mike Frysinger f159663b08 newlib: stop clobbering LDFLAGS with non-standard $ldflags
It's unclear why this was added originally, but assuming it was needed
20 years ago, it shouldn't be explicitly required nowadays.  Current
versions of autotools already take care of exporting LDFLAGS to the
Makefile as needed (things are actually getting linked).  That's why
the configure diffs show LDFLAGS still here, but shifted to a diff
place in the output list.  A few dirs stop exporting LDFLAGS, but
that's because they don't do any linking, only compiling, so it's
correct.

As for the use of $ldflags instead of the standard $LDFLAGS, I can't
really explain that at all.  Just use the right name so users don't
have to dig into why their setting isn't respected, and then use a
non-standard name instead.  Adjust the testsuite to match.
2022-01-21 17:10:10 -05:00
Mike Frysinger 4317e0676a newlib: stop checking --enable-multilib in subdirs
None of the subdirs actually use the multilib arg, so include the
logic only in the top-level configure.
2022-01-21 17:10:10 -05:00
Mike Frysinger 6783cceb0a newlib: libm: switch to autoconf long double macro
Now that we require a recent version of autoconf, we can rely on this
macro working.  We shift the call in configure.ac down a little to
help keep the generated diff minimal -- there should be no functional
difference otherwise.  This is because the autoconf macros will call
a bunch of standard toolchain macros first, and arguably the current
code is incorrect in how it does its testing.
2022-01-19 18:51:04 -05:00
Mike Frysinger 6746e06043 newlib: avoid duplicate awk checks
Since AM_INIT_AUTOMAKE calls AC_PROG_AWK, and some configure.ac
scripts call it too, we end up testing for awk multiple times.  If
we change NEWLIB_CONFIGURE to require the macro instead, then it
makes sure it's always expanded, but only once.

While we're here, do the same thing with AC_PROG_INSTALL since it
is also called by AM_INIT_AUTOMAKE, although it doesn't currently
result in duplicate configure checks.
2022-01-18 19:25:18 -05:00
Mike Frysinger 3722489f1f newlib: merge old AC_LIBTOOL_WIN32_DLL macro into LT_INIT
The AC_LIBTOOL_WIN32_DLL macro has been deprecated for a while and code
should call LT_INIT with win32-dll instead.  Update the calls to match.

The generated code is noisy not because of substantial differences, but
because the order of some macros change (i.e. instead of calling AS and
then CC, CC is called first and then AS).
2022-01-18 19:15:44 -05:00
Mike Frysinger fe591ba3f7 newlib: update libtool macro name
Replace old AM_PROG_LIBTOOL name with LT_INIT.  There's no change to
the generated files since they're aliases internally.
2022-01-18 19:15:44 -05:00
Mike Frysinger 71086e8b2d newlib: delete (most) redundant lib_a_CCASFLAGS=$(AM_CCASFLAGS)
Since automake already sets per-library CCASFLAGS to $(AM_CCASFLAGS)
by default, there's no need to explicitly set it here.

Many of these dirs don't have .S files in the first place, so the rule
doesn't even do anything.  That can easily be seen when Makefile.in has
no changes as a result.

For the dirs with .S files, the custom rules are the same as the pattern
.S.o rules, so this is a nice cleanup.

The only dir that was adding extra flags (newlib/libc/machine/mn10300/)
to the per-library setting can have it moved to the global AM_CCASFLAGS
since the subdir only has one target.  Although the setting just adds
extra debugging flags, so maybe it should be deleted in general.

There are a few dirs that we leave the redundant setting in place.  This
is to workaround an automake limitation in subdirs that support building
with & w/out libtool:
https://www.gnu.org/software/automake/manual/html_node/Objects-created-both-with-libtool-and-without.html
2022-01-18 19:12:02 -05:00
Mike Frysinger 20e3103471 newlib: update to automake-1.15
This matches what the other GNU toolchain projects have done already.
The generated diff in practice isn't terribly large.  This will allow
more use of subdir local.mk includes due to fixes & improvements that
came after the 1.11 release series.
2022-01-14 19:10:38 -05:00
Mike Frysinger a100e80fc9 require autoconf-2.69 exactly
The newlib & libgloss dirs are already generated using autoconf-2.69.
To avoid merging new code and/or accidental regeneration using diff
versions, leverage config/override.m4 to pin to 2.69 exactly.  This
matches what gcc/binutils/gdb are already doing.

The README file already says to use autoconf-2.69.

To accomplish this, it's just as simple as adding -I flags to the
top-level config/ dir when running aclocal.  This is because the
override.m4 file overrides AC_INIT to first require the specific
autoconf version before calling the real AC_INIT.
2022-01-14 15:24:33 -05:00
Nick Alcock 5ab7dd14e1 libtool.m4: fix nm BSD flag detection
Libtool needs to get BSD-format (or MS-format) output out of the system
nm, so that it can scan generated object files for symbol names for
-export-symbols-regex support.  Some nms need specific flags to turn on
BSD-formatted output, so libtool checks for this in its AC_PATH_NM.
Unfortunately the code to do this has a pair of interlocking flaws:

 - it runs the test by doing an nm of /dev/null.  Some platforms
   reasonably refuse to do an nm on a device file, but before now this
   has only been worked around by assuming that the error message has a
   specific textual form emitted by Tru64 nm, and that getting this
   error means this is Tru64 nm and that nm -B would work to produce
   BSD-format output, even though the test never actually got anything
   but an error message out of nm -B.  This is fixable by nm'ing *nm
   itself* (since we necessarily have a path to it).

 - the test is entirely skipped if NM is set in the environment, on the
   grounds that the user has overridden the test: but the user cannot
   reasonably be expected to know that libtool wants not only nm but
   also flags forcing BSD-format output.  Worse yet, one such "user" is
   the top-level Cygnus configure script, which neither tests for
   nor specifies any BSD-format flags.  So platforms needing BSD-format
   flags always fail to set them when run in a Cygnus tree, breaking
   -export-symbols-regex on such platforms.  Libtool also needs to
   augment $LD on some platforms, but this is done unconditionally,
   augmenting whatever the user specified: the nm check should do the
   same.

   One wrinkle: if the user has overridden $NM, a path might have been
   provided: so we use the user-specified path if there was one, and
   otherwise do the path search as usual.  (If the nm specified doesn't
   work, this might lead to a few extra pointless path searches -- but
   the test is going to fail anyway, so that's not a problem.)

(Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a
symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where
*that* is a symlink to /usr/bin/nm.)

ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

	PR libctf/27967
	* libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
	NM, if there is one.  Run nm on itself, not on /dev/null, to avoid
	errors from nms that refuse to work on non-regular files.  Remove
	other workarounds for this problem.  Strip out blank lines from the
	nm output.
2022-01-12 08:49:10 -05:00
Nick Alcock 4fe13b8d95 libtool.m4: augment symcode for Solaris 11
This reports common symbols like GNU nm, via a type code of 'C'.

ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

	PR libctf/27967
	* libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for
	Solaris 11.
2022-01-12 08:47:00 -05:00
Alexander von Gluck IV 8a563bfdd7 Add support for the haiku operating system. These are the os support patches we have been grooming and maintaining for quite a few years over on git.haiku-os.org. All of these architectures are working and most have been stable for quite some time. 2022-01-12 08:43:25 -05:00
H.J. Lu 88d86e5970 GCC: Check if AR works with --plugin and rc
AR from older binutils doesn't work with --plugin and rc:

[hjl@gnu-cfl-2 bin]$ touch foo.c
[hjl@gnu-cfl-2 bin]$ ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
[hjl@gnu-cfl-2 bin]$ ./ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
./ar: no operation specified
[hjl@gnu-cfl-2 bin]$ ./ar --version
GNU ar (Linux/GNU Binutils) 2.29.51.0.1.20180112
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
[hjl@gnu-cfl-2 bin]$

Check if AR works with --plugin and rc before passing --plugin to AR and
RANLIB.

	PR ld/27173
	* configure: Regenerated.
	* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Check if AR works with
	--plugin and rc before enabling --plugin.

config/

	PR ld/27173
	* gcc-plugin.m4 (GCC_PLUGIN_OPTION): Check if AR works with
	--plugin and rc before enabling --plugin.

libiberty/

	PR ld/27173
	* configure: Regenerated.

zlib/

	PR ld/27173
	* configure: Regenerated.
2022-01-12 08:43:14 -05:00
H.J. Lu d8d5dac0fe GCC: Pass --plugin to AR and RANLIB
Detect GCC LTO plugin.  Pass --plugin to AR and RANLIB to support LTO
build.

	* Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@
	(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
	* configure.ac: Include config/gcc-plugin.m4.
	AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION.
	* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Pass --plugin to AR and
	RANLIB if possible.
	* Makefile.in: Regenerated.
	* configure: Likewise.

config/

	* gcc-plugin.m4 (GCC_PLUGIN_OPTION): New.

libiberty/

	* Makefile.in (AR): Add @AR_PLUGIN_OPTION@
	(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
	(configure_deps): Depend on ../config/gcc-plugin.m4.
	* aclocal.m4: Include ../config/gcc-plugin.m4.
	* configure.ac: AC_SUBST AR_PLUGIN_OPTION and
	RANLIB_PLUGIN_OPTION.
	* configure: Regenerated.

zlib/

	* configure: Regenerated.
2022-01-12 08:43:05 -05:00
Samuel Thibault 4a3b4d50e3 libtool.m4: update GNU/Hurd test from upstream. In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink. This backports it.
.	* libtool.m4: Match gnu* along other GNU systems.

*/ChangeLog:

	* configure: Re-generate.
2022-01-12 07:19:46 -05:00
Mike Frysinger 8fc6b4b30e newlib: regen aclocal.m4 after autoconf update
The configure scripts were regenerated with 2.69 for the newlib-4.2.0
release in 484d2ebf8d, but the aclocal
files were not.  Do that now to avoid confusion between the two as to
which version of autoconf was used.
2022-01-12 07:01:18 -05:00
Mike Frysinger 54d77a0a56 newlib: use .texi with libc & libm manuals
Newer automake warns that .texinfo extensions are discouraged in favor
of .texi, so rename the manuals to match.
2022-01-07 15:54:10 -05:00
Mike Frysinger ed20821a40 newlib: migrate from INCLUDES to AM_CPPFLAGS
Since automake deprecated the INCLUDES name in favor of AM_CPPFLAGS,
change all existing users over.  The generated code is the same since
the two variables have been used in the same exact places by design.

There are other cleanups to be done, but lets focus on just renaming
here so we can upgrade to a newer automake version w/out triggering
new warnings.
2022-01-05 20:29:53 -05:00
Jeff Johnston 484d2ebf8d Update newlib to 4.2.0 2021-12-31 12:46:13 -05:00
Jon Turney bfcabeb876
newlib: Regenerate autotools files 2021-12-29 22:45:06 +00:00
Jon Turney a4e734fcdb
newlib: Remove automake option 'cygnus'
The 'cygnus' option was removed from automake 1.13 in 2012, so the
presence of this option prevents that or a later version of automake
being used.

A check-list of the effects of '--cygnus' from the automake 1.12
documentation, and steps taken (where possible) to preserve those
effects (See also this thread [1] for discussion on that):

[1] https://lists.gnu.org/archive/html/bug-automake/2012-03/msg00048.html

1. The foreign strictness is implied.

Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4

2. The options no-installinfo, no-dependencies and no-dist are implied.

Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4

Future work: Remove no-dependencies and any explicit header dependencies,
and use automatic dependency tracking instead.  Are there explicit rules
which are now redundant to removing no-installinfo and no-dist?

3. The macro AM_MAINTAINER_MODE is required.

Already present in newlib/acinclude.m4

Note that maintainer-mode is still disabled by default.

4. Info files are always created in the build directory, and not in the
source directory.

This appears to be an error in the automake documentation describing
'--cygnus' [2]. newlib's info files are generated in the source
directory, and no special steps are needed to keep doing that.

[2] https://lists.gnu.org/archive/html/bug-automake/2012-04/msg00028.html

5. texinfo.tex is not required if a Texinfo source file is specified.
(The assumption is that the file will be supplied, but in a place that
automake cannot find.)

This effect is overriden by an explicit setting of the TEXINFO_TEX
variable (the directory part of which is fed into texi2X via the
TEXINPUTS environment variable).

6. Certain tools will be searched for in the build tree as well as in the
user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.

For obscure automake reasons, this effect of '--cygnus' is not active
for makeinfo in newlib's configury.

However, there appears to be top-level configury which selects in-tree
runtest, expect and makeinfo, if present. So, if that works as it
appears, this effect is preserved. If not, this may cause problem if
anyone is building those tools in-tree.

This effect is not preserved for texi2dvi. This may cause problems if
anyone is building texinfo in-tree.

If needed, explicit checks for those tools looking in places relative to
$(top_srcdir)/../ as well as in PATH could be added.

7. The check target doesn't depend on all.

This effect is not preseved. The check target now depends on the all
target.

This concern seems somewhat academic given the current state of the
testsuite.

Also note that this doesn't touch libgloss.
2021-12-29 22:45:04 +00:00
Jon Turney 8e166351b3
newlib: Regenerate autotools files 2021-12-29 22:45:03 +00:00
Jon Turney 320510de2c
newlib: Make effects of 'cygnus' explicit
Add all the effects of 'cygnus' for which there exists an explicit way
to request that behaviour:

* Implied foreign strictness and options no-installinfo, no-dependencies
and no-dist are added to AM_INIT_AUTOMAKE in newlib/acinclude.m4.

* macro AM_MAINTAINER_MODE is added to newlib/acinclude.m4.

* For the implied TEXINFO_TEX of '$(top_srcdir)/../texinfo/texinfo.tex',
an explicit TEXINFO_TEX is always relative to $(srcdir), so write the
same pathname in that form.

This is to prepare for the removal of the automake option '--cygnus'.
2021-12-29 22:44:49 +00:00
Jon Turney 639cb7ec1a
newlib: Regenerate all autotools files
Regenerate all aclocal.m4, configure and Makefile.in files.
2021-12-09 21:41:35 +00:00
Takashi Yano 34876c05a5 frexpl: Support smaller long double of LDBL_MANT_DIG == 53.
- Currently, frexpl() supports only the following cases.
    1) LDBL_MANT_DIG == 64 or 113
    2) 'long double' is equivalent to 'double'
  This patch add support for LDBL_MANT_DIG == 53.
2021-12-03 19:14:03 +09:00
Jeff Johnston 8fa73a9f84 Modifying patch from: marian.buschsieweke@ovgu.de
The code accessing the floating point control/status register, namely

	#define	__cfc1(__fcsr)	__asm __volatile("cfc1 %0, $31" : "=r" (__fcsr)

does not compile with mips16. This changed the makefile to pass -mno-mips16 to avoid the following
compiler error:

	mips-mti-elf fails with "Error: unrecognized opcode `cfc1 $3,$31'"
2021-11-30 11:23:39 -05:00
Takashi Yano 48f6c59332 stdio: Fix issue of printing "%La" format with large exp part.
- Currently, printf("%La\n", 1e1000L) crashes with segv due to lack
  of frexpl() function. With this patch, frexpl() function has been
  implemented in libm to solve this issue.

Addresses: https://sourceware.org/pipermail/newlib/2021/018718.html
2021-11-29 22:51:16 +09:00
Mike Frysinger 59e83de0b1 libgloss/newlib: update configure.ac in Makefile.in files
The maintainer rules refer to configure.in directly, so update that
after renaming all the configure.ac files.
2021-11-06 14:14:49 -04:00
Mike Frysinger 920617998e libgloss/newlib: rename configure.in to configure.ac
The .in name has been deprecated for a long time in favor of .ac.
2021-09-13 10:14:37 -04:00
Corinna Vinschen 76c2c7a891 ldexp/ldexpf: avoid assembler warning
libm/machine/i386/f_ldexp.S:30: Warning: no instruction mnemonic suffix given and no register operands; using default for `fild'
libm/machine/i386/f_ldexpf.S:30: Warning: no instruction mnemonic suffix given and no register operands; using default for `fild'

fix this by adding the l mnemonic suffix

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-09-03 12:52:47 +02:00
Kito Cheng ca7b4bd236 libm: Fixing overflow handling issue for scalbnf and scalbn
cc Aldy Hernandez <aldyh@redhat.com> and Andrew MacLeod <amacleod@redhat.com>,
they are author of new VRP analysis for GCC, just to make sure I didn't
mis-understanding or mis-interpreting anything on GCC site.

GCC 11 have better value range analysis, that give GCC more confidence
to perform more aggressive optimization, but it cause scalbn/scalbnf get
wrong result.

Using scalbn to demostrate what happened on GCC 11, see comments with VRP
prefix:

```c
double scalbn (double x, int n)
{
	/* VRP RESULT: n = [-INF, +INF] */
        __int32_t  k,hx,lx;
        ...
        k = (hx&0x7ff00000)>>20;
	/* VRP RESULT: k = [0, 2047] */
        if (k==0) {
	    /* VRP RESULT: k = 0 */
	    ...
	    k = ((hx&0x7ff00000)>>20) - 54;
            if (n< -50000) return tiny*x;       /*underflow*/
	    /* VRP RESULT: k = -54 */
	}
	/* VRP RESULT: k = [-54, 2047] */
        if (k==0x7ff) return x+x;               /* NaN or Inf */
	/* VRP RESULT: k = [-54, 2046] */
        k = k+n;
        if (k > 0x7fe) return huge*copysign(huge,x); /* overflow  */
	/* VRP RESULT: k = [-INF, 2046] */
	/* VRP RESULT: n = [-INF, 2100],
	   because k + n <= 0x7fe is false, so:
	   1. -INF < [-54, 2046] + n <= 0x7fe(2046) < INF
	   2. -INF < [-54, 2046] + n <= 2046 < INF
	   3. -INF < n <= 2046 - [-54, 2046] < INF
	   4. -INF < n <= [0, 2100] < INF
	   5. n = [-INF, 2100] */
        if (k > 0)                              /* normal result */
            {SET_HIGH_WORD(x,(hx&0x800fffff)|(k<<20)); return x;}
        if (k <= -54) {
	    /* VRP OPT: Evaluate n > 50000 as true...*/
            if (n > 50000)      /* in case integer overflow in n+k */
                return huge*copysign(huge,x);   /*overflow*/
            else return tiny*copysign(tiny,x);  /*underflow*/
	}
        k += 54;                                /* subnormal result */
        SET_HIGH_WORD(x,(hx&0x800fffff)|(k<<20));
        return x*twom54;
}
```

However give the input n = INT32_MAX, k = k+n will overflow, and then we
expect got `huge*copysign(huge,x)`, but new VRP optimization think
`n > 50000` is never be true, so optimize that into `tiny*copysign(tiny,x)`.

so the solution here is to moving the overflow handle logic before `k = k + n`.
2021-07-21 09:56:04 +02:00
Jeff Johnston a9165ea07c Fix rounding issues with sqrt/sqrtf
- compiler is sometimes optimizing out the rounding check in
  e_sqrt.c and ef_sqrt.c which uses two constants to create
  an inexact operation
- there is a similar constant operation in s_tanh.c/sf_tanh.c
- make the one and tiny constants volatile to stop this
2021-06-04 14:42:58 -04:00
Ties Stuij 282445a10e fix some Arm FP routines not checking if floating point is enabled
A lot of the Arm FP routines check for the availability of floating point by way
of `(__ARM_FP & 0x4)`. However some do not. This patch remedies this.
2021-04-21 16:18:09 +01:00
David Macek 7078248485 fenv: fix up stub file comment, drop symlinks from description
also slightly fixed up formatting
2021-04-13 12:55:34 +02:00
Corinna Vinschen cc19109af9 Cygwin: don't export _feinitialise from newlib
Use the more official fesetenv(FE_DFL_ENV) from _dll_crt0, thus
allowing to drop the _feinitialise declaration from fenv.h.

Provide a no-op _feinitialise in Cygwin as exportable symbol for really
old applications when _feinitialise was called from mainCRTStartup in
crt0.o.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-04-13 12:55:34 +02:00
Corinna Vinschen 3b22d72255 fenv: drop Cygwin-specific implementation in favor of newlib code
Drop the Cygwin-specific fenv.cc and fenv.h file and use the equivalent
newlib functionality now, so we have at least one example of a user for
this new mechanism.

fenv.c: allow _feinitialise to be called from Cygwin startup code

fenv.h: add declarations for fegetprec and fesetprec for Cygwin only.
        Fix a comment.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-04-13 12:55:34 +02:00
Corinna Vinschen 642be00cdb fenv: move shared x86 fenv.c to libm/machine/shared_x86
Include this file from both sharing architectures, i386 and x86_64.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-04-13 12:55:33 +02:00
Corinna Vinschen 80bd01ef83 Add build mechanism to share common header files between machines
So far the build mechanism in newlib only allowed to either define
machine-specific headers, or headers shared between all machines.
In some cases, architectures are sufficiently alike to share header
files between them, but not with other architectures.  A good example
is ix86 vs. x86_64, which share certain traits with each other, but
not with other architectures.

Introduce a new configure variable called "shared_machine_dir".  This
dir can then be used for headers shared between architectures.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-04-13 12:55:33 +02:00
Eshan dhawan 55a6e49a08 Removed Soft float from MIPS
This Patch removes Soft Float code from MIPS.
Instead It adds the soft float code from RISCV

The code came from FreeBSD and assumes the FreeBSD softfp
implementation not the one with GCC. That was an overlooked and
fixed in the other fenv code already.

Signed-off-by: Eshan Dhawan <eshandhawan51@gmail.com>
2021-02-05 10:32:16 +01:00
Jeff Johnston 415fdd4279 Bump up newlib version to 4.1.0 2020-12-18 18:50:49 -05:00
Paul Zimmermann 4bb6581aa8 fixes to make compilation succeeds 2020-12-18 10:06:31 +01:00
Jeff Johnston b2f3d593ff Update gamma functions from code in picolibc
- fixes issue with inf sign when x is -0
2020-12-17 16:23:43 -05:00
Jeff Johnston d634f26653 Add declarations for __ieee754_tgamma functions to fdlibm.h 2020-12-16 15:28:09 -05:00
Fabian Schriever cf1ef2dc5b Fix error in powf for x close to 1 and large y
This patch fixes the error found by Paul Zimmermann (see
https://homepages.loria.fr/PZimmermann/papers/#accuracy) regarding x
close to 1 and rather large y (specifically he found the case
powf(0x1.ffffeep-1,-0x1.000002p+27) which returns +Inf instead of the
correct value). We found 2 more values for x which show the same faulty
behaviour, and all 3 are fixed with this patch. We have tested all
combinations for x in [+1.fffdfp-1, +1.00020p+0] and y in
[-1.000007p+27, -1.000002p+27] and [1.000002p+27,1.000007p+27].
2020-12-11 14:38:19 -05:00
Jeff Johnston 14123c991b Bump newlib release to 4.0.0 2020-12-11 14:37:12 -05:00
Kito Cheng 57635f8581 RISC-V: Add machine-specific implementation for lrint[f], lround[f], llrint[f] and llround[f]. 2020-11-18 09:35:28 +01:00
Kito Cheng 5cf5a2e4c0 RISC-V: Add machine-specific implementation for isnan[f] and copysign[f] 2020-11-18 09:35:28 +01:00
Kito Cheng a7f82939d8 RISC-V: Add missing compile rule for s_finite.c, sf_finite.c, s_isinf.c and sf_isinf.c 2020-11-18 09:35:28 +01:00
Kito Cheng ff2c8fcfc7 RISC-V: Fix wrong including file in s_isinf.c 2020-10-29 09:39:35 +01:00
Kito Cheng 0020d2dd7c RISC-V: NaN should return 0 for finite[f] 2020-10-29 09:39:35 +01:00
Kito Cheng b847c83294 RISC-V: Implment finite and fpclassify 2020-10-27 08:56:30 +01:00
Kito Cheng b5f03509d1 RISC-V: Add fabs[f], fmax[f] and fmin[f]. 2020-10-27 08:56:30 +01:00
Keith Packard 4641693796 libm: Make tgamma(-small) = -INFINITY
Need to copy the argument sign to the output for tgamma(finite)
overflow case.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-09-18 17:20:27 -04:00
Keith Packard via Newlib 1f8e5847df libm: Fix 'gamma' and 'gammaf' functions. Clean up other gamma code. [v2]
The current gamma, gamma_r, gammaf and gammaf_r functions return
|gamma(x)| instead of ln(|gamma(x)|) due to a change made back in 2002
to the __ieee754_gamma_r implementation. This patch fixes that, making
all of these functions map too their lgamma equivalents.

To fix the underlying bug, the __ieee754_gamma functions have been
changed to return gamma(x), removing the _r variants as those are no
longer necessary. Their names have been changed to __ieee754_tgamma to
avoid potential confusion from users.

Now that the __ieee754_tgamma functions return the correctly signed
value, the tgamma functions have been modified to use them.

libm.a now exposes the following gamma functions:

    ln(|gamma(x)|):

	__ieee754_lgamma_r
	__ieee754_lgammaf_r

	lgamma
	lgamma_r
	gamma
	gamma_r

	lgammaf
	lgammaf_r
	gammaf
	gammaf_r

	lgammal	(on machines where long double is double)

    gamma(x):

	__ieee754_tgamma
	__ieee754_tgammaf
	tgamma
	tgammaf
	tgammal (on machines where long double is double)

Additional aliases for any of the above functions can be added if
necessary; in particular, I'm not sure if we need to include
__ieee754_gamma*_r functions (which would return ln(|(gamma(x)|).

Signed-off-by: Keith Packard <keithp@keithp.com>

----

v2:
	Switch commit message to ASCII
2020-09-04 21:27:11 +02:00
Keith Packard via Newlib a0d7982ff4 libm/riscv: Use common fma code when necessary
For RISC-V targets without hardware FMA support, include the
common fma implementation to provide that API.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-09-04 15:11:31 +02:00
Keith Packard via Newlib 373f628d04 libm/riscv: Fix machine-specific sqrt build process
Like ARM, some RISC-V implementations have hardware sqrt. Support for
that can be detected at compile time, which the code did. However, the
filenames were incorrect so that both the risc-v specific and general
code were getting included in the resulting library.

Fix this by following the ARM model and #include'ing the general code
when the architecture-specific support is not available.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-09-04 15:11:31 +02:00
Keith Packard via Newlib a634adda5a libm/machine/arm: Rename s*_fma.c -> s*_fma_arm.c
This is required to avoid colliding with files built from libm/common
that would end up with the same object name.

When libm.a was constructed from the individual sub-libraries, the
contents of the libm/common files would be replaced by that from
libm/machine/arm with the same name.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-09-02 10:04:30 +02:00
Keith Packard via Newlib bafd65f2fb libm/machine/riscv: Add custom fma/sqrt functions when supported [v2]
Check for HW FMA and SQRT support and use those instructions in place
of software implementations.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-12 09:52:19 +02:00
Keith Packard via Newlib a44bc679a4 libm/machine/arm: Add optimized fmaf and fma when available
When HAVE_FAST_FMAF is set, use the vfma.f32 instruction, when
HAVE_FAST_FMA is set, use the vfma.f64 instruction.

Usually the compiler built-ins will already have inlined these
instructions, but provide these symbols for cases where that doesn't
work instead of falling back to the (inaccurate) common code versions.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-10 21:04:12 +02:00
Keith Packard via Newlib 0c1989070e libm: Detect fast fmaf support
Anything with fast FMA is assumed to have fast FMAF, along with
32-bit arms that advertise 32-bit FP support and __ARM_FEATURE_FMA

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-10 21:01:46 +02:00
Keith Packard via Newlib 432b331c79 libm: ARM without HW double does not have fast FMA
32-bit ARM processors with HW float (but not HW double) may define
__ARM_FEATURE_FMA, but that only means they have fast FMA for 32-bit
floats.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-10 21:01:46 +02:00
Keith Packard via Newlib 73b02710ec libm/math: ensure that expf(-huge) sets FE_UNDERFLOW exception
It was calling __math_uflow(0) instead of __math_uflowf(0), which
resulted in no exception being set on machines with exception support
for float but not double.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-10 10:31:36 +02:00
Keith Packard via Newlib c3ce8405c1 libm: Control errno support with _IEEE_LIBM configuration parameter
This removes the run-time configuration of errno support present in
portions of the math library and unifies all of the compile-time errno
configuration under a single parameter so that the whole library
is consistent.

The run-time support provided by _LIB_VERSION is no longer present in
the public API, although it is still used internally to disable errno
setting in some functions. Now that it is a constant, the compiler should
remove that code when errno is not supported.

This removes s_lib_ver.c as _LIB_VERSION is no longer variable.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-05 22:23:02 +02:00
Keith Packard via Newlib e108d04432 libm/math: Don't modify __ieee754_pow return values in pow
The __ieee754 functions already return the right value in exception
cases, so don't modify those. Setting the library to _POSIX_/_IEEE_
mode now only affects whether errno is modified.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-05 22:16:31 +02:00
Keith Packard via Newlib 98a4f8de47 libm/math: Set errno to ERANGE for pow(0, -y)
POSIX says that the errno for pow(0, -y) should be ERANGE instead of
EDOM.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/pow.html

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-05 22:16:31 +02:00
Keith Packard via Newlib 2eafcc78df libm/math: Make yx functions set errno=ERANGE for x=0
The y0, y1 and yn functions need separate conditions when x is zero as
that returns ERANGE instead of EDOM.

Also stop adjusting the return value from the __ieee754_y* functions
as that is already correct and we were just breaking it.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-05 22:16:31 +02:00
Keith Packard via Newlib 905aa4c013 libm/math: set errno to ERANGE at gamma poles
For POSIX, gamma(i) (i non-positive integer) should set errno to
ERANGE instead of EDOM.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-05 22:16:31 +02:00
Keith Packard via Newlib bb166cfc3e libm/common: Set WANT_ERRNO based on _IEEE_LIBM value
_IEEE_LIBM is the configuration value which controls whether the
original libm functions modify errno. Use that in the new math code as
well so that the resulting library is internally consistent.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-08-04 19:30:45 +02:00
Keith Packard 12ad9a46df libm/math: Use __math_xflow in obsolete math code [v2]
C compilers may fold const values at compile time, so expressions
which try to elicit underflow/overflow by performing simple
arithemetic on suitable values will not generate the required
exceptions.

Work around this by replacing code which does these arithmetic
operations with calls to the existing __math_xflow functions that are
designed to do this correctly.

Signed-off-by: Keith Packard <keithp@keithp.com>

----

v2:
	libm/math: Pass sign to __math_xflow instead of muliplying result
2020-08-03 13:29:27 +02:00
Sebastian Huber ba283d8777 arm: Fix include to avoid undefined reference
ld: libm.a(lib_a-fesetenv.o): in function `fesetenv':
newlib/libm/machine/arm/fesetenv.c:38: undefined reference to `vmsr_fpscr'

Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
2020-07-29 16:24:13 +02:00
Eshan dhawan 3ca4325968 arm: Split fenv.c into multiple files
Use the already existing stub files if possible.  These files are
necessary to override the stub implementation with the machine-specific
implementation through the build system.

Reviewed-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
2020-07-29 06:58:17 +02:00
Eshan dhawan b7a6e02dc6 arm: Fix fenv support
The previous fenv support for ARM used the soft-float implementation of
FreeBSD.  Newlib uses the one from libgcc by default.  They are not
compatible.  Having an GCC incompatible soft-float fenv support in
Newlib makes no sense.  A long-term solution could be to provide a
libgcc compatible soft-float support.  This likely requires changes in
the GCC configuration.  For now, provide a stub implementation for
soft-float multilibs similar to RISC-V.

Move implementation to one file and delete now unused files.  Hide
implementation details.  Remove function parameter names from header
file to avoid name conflicts.

Provide VFP support if __SOFTFP__ is not defined like glibc.

Reviewed-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
2020-07-29 06:58:17 +02:00
Corinna Vinschen f095752167 libm: machine: Add missing sparc and mips configuration
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2020-07-03 10:45:44 +02:00
Eshan dhawan via Newlib 65918715a0 mips fenv support
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
2020-07-03 10:41:45 +02:00
Eshan dhawan via Newlib 03bf9f431c SPARC fenv support
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
2020-07-03 10:41:45 +02:00
Eshan dhawan via Newlib fd5e27d362 fenv aarch64 support
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
2020-07-02 12:12:39 +02:00
Eshan dhawan via Newlib a97bdf100f fenv support arm
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
2020-06-09 21:13:17 -04:00
Jeff Johnston bc5087298d Regenerate libm/machine configuration files for powerpc 2020-06-09 20:59:04 -04:00
Eshan dhawan via Newlib e6ce6f1430 hard float support for PowerPC taken from FreeBSD
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
2020-06-03 11:17:47 +02:00
Keith Packard via Newlib 6295d75913 newlib/libm/math: Make pow/powf return qnan for snan arg
The IEEE spec for pow only has special case for x**0 and 1**y when x/y
are quiet NaN. For signaling NaN, the general case applies and these functions
should signal the invalid exception and return a quiet NaN.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-03-26 12:21:33 +01:00
Keith Packard via Newlib 3439f3b0e9 newlib/libm/common: Don't re-convert float to bits in modf/modff
These functions shared a pattern of re-converting the argument to bits
when returning +/-0. Skip that as the initial conversion still has the
sign bit.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-03-26 12:21:33 +01:00
Keith Packard via Newlib 61cd34c1bf newlib/libm/common: Fix modf/modff returning snan
Recent GCC appears to elide multiplication by 1, which causes snan
parameters to be returned unchanged through *iptr. Use the existing
conversion of snan to qnan to also set the correct result in *iptr
instead.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-03-26 12:21:33 +01:00
Joseph S. Myers 5e24839658 Fix spurious underflow exceptions for Bessel functions for double(from glibc bug 14155)
This fix comes from glibc, from files which originated from
	the same place as the newlib files. Those files in glibc carry
	the same license as the newlib files.

Bug 14155 is spurious underflow exceptions from Bessel functions for
large arguments.  (The correct results for large x are roughly
constant * sin or cos (x + constant) / sqrt (x), so no underflow
exceptions should occur based on the final result.)

There are various places underflows may occur in the intermediate
calculations that cause the failures listed in that bug.  This patch
fixes problems for the double version where underflows occur in
calculating the intermediate functions P and Q (in particular, x**-12
gets computed while calculating Q).  Appropriate approximations are
used for P and Q for arguments at least 0x1p28 and above to avoid the
underflows.

For sufficiently large x - 0x1p129 and above - the code already has a
cut-off to avoid calculating P and Q at all, which means the
approximations -0.125 / x and 0.375 / x can't themselves cause
underflows calculating Q.  This cut-off is heuristically reasonable
for the point beyond which Q can be neglected (based on expecting
around 0x1p-64 to be the least absolute value of sin or cos for large
arguments representable in double).

The float versions use a cut-off 0x1p17, which is less heuristically
justifiable but should still only affect values near zeroes of the
Bessel functions where these implementations are intrinsically
inaccurate anyway (bugs 14469-14472), and should serve to avoid
underflows (the float underflow for jn in bug 14155 probably comes
from the recurrence to compute jn).  ldbl-96 uses 0x1p129, which may
not really be enough heuristically (0x1p143 or so might be safer - 143
= 64 + 79, number of mantissa bits plus total number of significant
bits in representation) but again should avoid underflows and only
affect values where the code is substantially inaccurate anyway.
ldbl-128 and ldbl-128ibm share a completely different implementation
with no such cut-off, which I propose to fix separately.

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-03-26 12:21:33 +01:00
Fabian Schriever 6b0c1e7cc8 Fix hypotf missing mask in hi+lo decomposition
Add the missing mask for the decomposition of hi+lo which caused some
errors of 1-2 ULP.

This change is taken over from FreeBSD:
95436ce20d

Additionally I've removed some variable assignments which were never
read before being overwritten again in the next 2 lines.
2020-03-19 16:46:17 +01:00
Fabian Schriever 4ad9ba42fc Fix modf/f for NaN input
For NaN input the modf/f procedures should return NaN instead of zero
with the sign of the input.
2020-03-19 16:34:26 +01:00
Fabian Schriever 9e8da7bd21 Fix for k_tan.c specific inputs
This fix for k_tan.c is a copy from fdlibm version 5.3 (see also
http://www.netlib.org/fdlibm/readme), adjusted to use the macros
available in newlib (SET_LOW_WORD).

This fix reduces the ULP error of the value shown in the fdlibm readme
(tan(1.7765241907548024E+269)) to 0.45 (thereby reducing the error by
1).

This issue only happens for large numbers that get reduced by the range
reduction to a value smaller in magnitude than 2^-28, that is also
reduced an uneven number of times. This seems rather unlikely given that
one ULP is (much) larger than 2^-28 for the values that may cause an
issue.  Although given the sheer number of values a double can
represent, it is still possible that there are more affected values,
finding them however will be quite hard, if not impossible.

We also took a look at how another library (libm in FreeBSD) handles the
issue: In FreeBSD the complete if branch which checks for values smaller
than 2^-28 (or rather 2^-27, another change done by FreeBSD) is moved
out of the kernel function and into the external function. This means
that the value that gets checked for this condition is the unreduced
value. Therefore the input value which caused a problem in the
fdlibm/newlib kernel tan will run through the full polynomial, including
the careful calculation of -1/(x+r). So the difference is really whether
r or y is used. r = y + p with p being the result of the polynomial with
1/3*x^3 being the largest (and magnitude defining) value. With x being
<2^-27 we therefore know that p is smaller than y (y has to be at least
the size of the value of x last mantissa bit divided by 2, which is at
least x*2^-51 for doubles) by enough to warrant saying that r ~ y.  So
we can conclude that the general implementation of this special case is
the same, FreeBSD simply has a different philosophy on when to handle
especially small numbers.
2020-03-18 10:05:11 +01:00
Fabian Schriever c56f53a2a0 Fix truncf for sNaN input
Make line 47 in sf_trunc.c reachable. While converting the double
precision function trunc to the single precision version truncf an error
was introduced into the special case. This special case is meant to
catch both NaNs and infinities, however qNaNs and infinities work just
fine with the simple return of x (line 51). The only error occurs for
sNaNs where the same sNaN is returned and no invalid exception is
raised.
2020-03-11 12:10:58 +01:00
Joel Sherrill 91a8d0c907 i386/fenv.c: Include fenv.c implementation shared with x86_64, not stub 2020-03-10 16:05:59 +01:00
Fabian Schriever 18b4e0e518 Fix error in fdim/f for infinities
The comparison c == FP_INFINITE causes the function to return +inf as it
expects x = +inf to always be larger than y. This shortcut causes
several issues as it also returns +inf for the following cases:
 - fdim(+inf, +inf), expected (as per C99): +0.0
 - fdim(-inf, any non NaN), expected: +0.0

I don't see a reason to keep the comparison as all the infinity cases
return the correct result using just the ternary operation.
2020-03-10 15:11:23 +01:00
Fabian Schriever a8a40ee575 Fix error in exp in magnitude [2e-32,2e-28]
While testing the exp function we noticed some errors at the specified
magnitude. Within this range the exp function returns the input value +1
as an output. We chose to run a test of 1m exponentially spaced values
in the ranges [-2^-27,-2^-32] and [2^-32,2^-27] which showed 7603 and
3912 results with an error of >=0.5 ULP (compared with MPFR in 128 bit)
with the highest being 0.56 ULP and 0.53 ULP.

It's easy to fix by changing the magnitude at which the input value +1
is returned from <2^-28 to <2^-32 and using the polynomial instead. This
reduces the number of results with an error of >=0.5 ULP to 485 and 479
in above tests, all of which are exactly 0.5 ULP.

As we were already checking on exp we also took a look at expf. For expf
the magnitude where the input value +1 is returned can be increased from
<2^-28 to <2^-23 without accuracy loss for a slight performance
improvement. To ensure this was the correct value we tested all values
in the ranges [-2^-17,-2^-28] and [2^-28,2^-17] (~92.3m values each).
2020-03-09 10:12:25 +01:00
Fabian Schriever d4bcecb3e9 Fix error in float trig. function range reduction
The single-precision trigonometric functions show rather high errors in
specific ranges starting at about 30000 radians. For example the sinf
procedure produces an error of 7626.55 ULP with the input
5.195880078125e+04 (0x474AF6CD) (compared with MPFR in 128bit
precision). For the test we used 100k values evenly spaced in the range
of [30k, 70k]. The issues are periodic at higher ranges.

This error was introduced when the double precision range reduction was
first converted to float. The shift by 8 bits always returns 0 as iq is
never higher than 255.

The fix reduces the error of the example above to 0.45 ULP, highest
error within the test set fell to 1.31 ULP, which is not perfect, but
still a significant improvement. Testing other previously erroneous
ranges no longer show particularly large accuracy errors.
2020-03-03 16:45:22 +01:00
Fabian Schriever cef36220f2 Fix error in powf for (-1.0, NaN) input
Prevent confusion between -1.0 and 1.0 in powf. The corresponding
similar error was previously fixed for pow (see commit bb25dd1b)
2020-03-02 16:46:03 +01:00
Joel Sherrill fbaa096772 x86_64/i386 fenv: Replace symlink with include fenv_stub.c
Having symlinks for these files led to an issue reported to the RTEMS
Project that showed up using some tar for native Windows to unpack the
newlib sources.  It creates symlinks in the tar file as copies of the
files the symlinks point to.  If the links appear in the tar file before
the source exists, it cannot copy the file.

The solution in this patch is to convert the files that are symbolic
links into simple files which include the file they were linked to.
This should be more portable and avoids the symbolinc link problem.
2020-02-25 16:42:19 +01:00
Nicolas Brunie bb25dd1b0f pow: fix pow(-1.0, NaN)
I think I may have encountered a bug in the implementation of pow:
pow(-1.0, NaN) returns 1.0 when it should return NaN.
Because ix is used to check input vs 1.0 rather than hx, -1.0 is
mistaken for 1.0
2020-02-14 10:12:25 +01:00
Keith Packard 10058b98e7 Typo in license terms for newlib/libm/common/log2.c
The closing quotes were in the wrong place

Signed-off-by: Keith Packard <keithp@keithp.com>
2020-02-06 11:58:50 +01:00
Jeff Johnston 4e78f8ea16 Bump up newlib release to 3.3.0 2020-01-21 15:17:43 -05:00
Jeff Johnston 1afb22a120 Bump up release to 3.2.0 for yearly snapshot 2020-01-02 14:56:24 -05:00
Keith Packard 7a526cdc28 libm: switch sf_log1p from double error routines to float
sf_log1p was using __math_divzero and __math_invalid, which
drag in a pile of double-precision code. Switch to using the
single-precision variants. This also required making those
available in __OBSOLETE_MATH mode.

Signed-off-by: Keith Packard <keithp@keithp.com>
2019-12-02 10:00:32 +01:00
Dimitar Dimitrov a1f617466d PRU: Align libmath to PRU ABI
The TI proprietary toolchain uses nonstandard names for some math
library functions. In order to achieve ABI compatibility between
GNU and TI toolchains, add support for the TI function names.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
2019-10-31 15:02:33 -04:00
Jeff Johnston 0764a2eab8 Fix some generated files 2019-10-31 14:52:04 -04:00