There are some sections which could be improved
and work to do so is on going. The work will be
covered via 'X-MFC-WITH' commits.
Obtained from: OpenBSD
Differential Revision: https://reviews.freebsd.org/D34759
(cherry picked from commit 4b7f35db44)
This look like a copy and paste leftover.
Reported by: enh@google.com (via freebsd-numerics@)
Reviewed by: Steve Kargl <sgk@troutmask.apl.washington.edu>
(cherry picked from commit 20d425842a)
Some of the functions in msun can be implemented using a compiler
builtin function to generate a small number of instructions. Implement
this support in fma, fmax, fmin, and sqrt on arm64.
Care must be taken as the builtin can be implemented as a function
call on some architectures that lack direct support. In these cases
we need to use the original code path.
As we don't set errno on failure build with -fno-math-errno so the
toolchain doesn't convert a builtin into a function call when it
detects a failure, e.g. gcc will add a call to sqrt when the input
is negative leading to an infinite loop.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32801
(cherry picked from commit b2e843161d)
In ac76bc1145, I added a few volatiles to work around ctrig_test
failures with {inf,inf}. This is not necessary anymore now, since in
3b00222f15 we added -fp-exception-behavior=maytrap for clang >= 10 in
libm's Makefile. (The flag tells clang to use stricter floating point
semantics, which libm depends on.)
PR: 244732, 254911
Fixes: ac76bc1145
(cherry picked from commit e2157cd000)
.Fa is the suitable macro for functions in comparsion to the
.Ar macro, which should be used for commandline arguments.
While here, fix some mandoc warnings.
Reviewed by: imp (earlier version)
Obtained from: OpenBSD (in partial)
Differential Revision: https://reviews.freebsd.org/D31090
(cherry picked from commit c5cbef2f85)
After df3b437c1e, older gcc's such as
4.2.1 (still used on earlier branches for e.g. mips and powerpc) and
6.3.0 (still used for some cross-builds) started throwing bogus errors
like:
In file included from /workspace/src/lib/msun/src/s_llround.c:11:0:
/workspace/src/lib/msun/src/s_lround.c:54:31: error: initializer element is not constant
static const type dtype_min = type_min - 0.5;
^~~~~~~~
/workspace/src/lib/msun/src/s_lround.c:55:31: error: initializer element is not constant
static const type dtype_max = type_max + 0.5;
^~~~~~~~
Since 'type_min' and 'type_max' are constants declared just above these
lines this error is nonsensical, but older gcc's are not smart enough.
Work around the error by reusing the (type)DTYPE_MIN and (type)DTYPE_MAX
macros, so I can MFC this right away, unbreaking a few stable builds.
(cherry picked from commit 0bcd49c13a)
It turned out that the (type)DTYPE_MAX conversions at the top of
s_lround.c are now emitted as cvtsi2sd instructions, at least on SSE
capable CPUs. This caused the FE_INEXACT flag to always be set, at least
for the double and float variants. Under clang 11, the whole INRANGE()
comparisons were still optimized away, but this has "improved" in clang
12, due to stricter adherence to the -ffp-exception-behavior=maytrap
compiler flag.
To avoid run-time integer to float conversions, use static constants
instead, so they are computed at compile time, and the INRANGE()
statements are optimized away again, if applicable.
While here, use an integer instead of a floating type to store the test
results in lround_test.c, as this is more appropriate, and we can also
drop the volatile hack.
Reported by: arichardson
(cherry picked from commit df3b437c1e)
For some reason the ld128 log1pl() implementation is less accurate than
logl(), but does at least guarantee precision >= the ld80 implementation.
Mark log1p_accuracy_tests as XFAIL for ld128 and increase the log1p tolerance
to the ld80 equivalent in accuracy_tests to avoid losing test coverage for
the other functions.
PR: 253984
Reviewed By: ngie, dim
Differential Revision: https://reviews.freebsd.org/D29039
(cherry picked from commit 1ad83445fc)
This avoids build failures due to the clang 12 warning:
'#pragma FENV_ACCESS' is not supported on this target - ignored
Clang 12 currently emits this warning for all non-x86 architectures.
While this can result in incorrect code generation (e.g. on AArch64 some
exceptions are not raised as expected), this is a pre-existing issue and
we should not fail the build due to this warning.
Reviewed By: dim, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29743
(cherry picked from commit 168234fa67)
The LLVM bug was fixed a long time ago and with D29076 this test actually
passes now.
Reviewed By: andrew
Differential Revision: https://reviews.freebsd.org/D29092
(cherry picked from commit dbb2d6f5e1)
If long double has more than 64 mantissa bits, using uint64_t to hold the
mantissa bits will truncate the value and result in test failures. To fix
this problem use __uint128_t since all platforms that have
__LDBL_MANT_DIG__ > 64 also have compiler support for 128-bit integers.
Reviewed By: rlibby
Differential Revision: https://reviews.freebsd.org/D29076
(cherry picked from commit ce88eb476b)
I only tested the WARNS=6 change on AArch64 and AMD64, but this file has
unused functions for architectures with LDBL_PREC == 53.
While touching this file change the LDBL_PREC == 53 checks to i386 checks.
The long double tests should only be disabled for i386 (due to the rather
odd rounding mode that it uses) not all architectures where long double
is the same as double.
PR: 205449
Fixes: 87d65c747a ("lib/msun: Allow building tests with WARNS=6")
Reported by: Jenkins
(cherry picked from commit 7f5693d053)
Output a hex dump of the current fenv and the expected value to allow
comparing them without having to resort to interactive use of GDB.
(cherry picked from commit 6ccdee8ab5)
Some CPUs (e.g. AArch64 QEMU) cannot trap on floating point exceptions and
therefore ignore the writes to the floating point control register inside
feenableexcept(). If no exceptions are enabled after
feenableexcept(FE_ALL_EXCEPT), we can assume that the CPU does not
support exceptions and we can then skip the test.
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D29095
(cherry picked from commit 2b9dbcd390)
Also print the mismatched values when numbers compare not equal.
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D29091
(cherry picked from commit b424e0038a)
These appears to have been resolved by compiling the test with -fno-builtin
and/or using a newer compiler.
PR: 208703
Reviewed By: ngie
Differential Revision: https://reviews.freebsd.org/D28884
(cherry picked from commit b358534ab1)
This provides better error messages that just an assertion failure and
also makes it easier to mark individual tests as XFAIL.
It was also helpful when coming up with D28786 and D28787.
Differential Revision: https://reviews.freebsd.org/D28798
(cherry picked from commit 133bc64507)
Apparently GCC only supports arithmetic expressions that use static
const variables in initializers starting with GCC8. To keep older
versions happy use a macro instead.
Fixes: 221622ec0c ("lib/msun: Avoid FE_INEXACT for x86 log2l/log10l")
Reported by: Jenkins
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D29233
(cherry picked from commit 05eac56a04)
This fixes tests/lib/msun/logarithm_test after compiling the test with
-fno-builtin (D28577). Adding invln10_lo + invln10_10 results in
FE_INEXACT (for all inputs) and the same for the log2l invln2_lo + invln2_hi.
This patch avoids FE_INEXACT (for exact results such as 0) by defining a
constant and using that.
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D28786
(cherry picked from commit 221622ec0c)
This caused LDBL_MANT_DIG to not be defined and therefore the scalbnl
alias was not being emitted for double==long double platforms.
Fixes: 760b2ffc ("Update scalbn* functions to the musl versions")
Reported by: Jenkins
(cherry picked from commit f5542795b9)
The only diff compared to musl is a minor change to scalbnl() to replace
musl's union ldshape with union IEEEl2bits.
This fixes the scalbn tests on non-x86 (since x86 has an assembly version
that is used instead).
Musl commit messages:
commit 8c44a060243f04283ca68dad199aab90336141db
Author: Szabolcs Nagy <nsz@port70.net>
Date: Mon Apr 3 02:38:13 2017 +0200
fix scalbn when result is in the subnormal range
in nearest rounding mode scalbn could introduce double rounding error
when an intermediate value and the final result were both in the
subnormal range e.g.
scalbn(0x1.7ffffffffffffp-1, -1073)
returned 0x1p-1073 instead of 0x1p-1074, because the intermediate
computation got rounded to 0x1.8p-1023.
with the fix an intermediate value can only be in the subnormal range
if the final result is 0 which is correct even after double rounding.
(there still can be two roundings so signals may be raised twice, but
that's only observable with trapping exceptions which is not supported.)
commit 2eaed464e2080d8321d3903b71086a1ecfc4ee4a
Author: Szabolcs Nagy <nsz@port70.net>
Date: Wed Sep 4 15:52:54 2013 +0000
math: use float_t and double_t in scalbnf and scalbn
remove STRICT_ASSIGN (c99 semantics is assumed) and use the conventional
union to prepare the scaling factor (so libm.h is no longer needed)
commit 1b77b9072f374bd26eb0574b83a0d5f18d75ec60
Author: Szabolcs Nagy <nsz@port70.net>
Date: Thu Aug 15 10:07:46 2013 +0000
math: minor scalbn*.c simplification
commit c4359e01303da2755fe7e8033826b132eb3659b1
Author: Szabolcs Nagy <nsz@port70.net>
Date: Tue Nov 13 10:55:35 2012 +0100
math: excess precision fix modf, modff, scalbn, scalbnf
old code was correct only if the result was stored (without the
excess precision) or musl was compiled with -ffloat-store.
now we use STRICT_ASSIGN to work around the issue.
(see note 160 in c11 section 6.8.6.4)
commit 666271c105e4137bdfa195e217799d74143370d4
Author: Szabolcs Nagy <nsz@port70.net>
Date: Tue Nov 13 10:30:40 2012 +0100
math: fix scalbn and scalbnf on overflow/underflow
old code was correct only if the result was stored (without the
excess precision) or musl was compiled with -ffloat-store.
(see note 160 in n1570.pdf section 6.8.6.4)
commit 8051e08e10d2b739fcfcbc6bc7466e8d77fa49f1
Author: nsz <nsz@port70.net>
Date: Mon Mar 19 10:54:07 2012 +0100
simplify scalbn*.c implementations
The old scalbn.c was wrong and slow, the new one is just slow.
(scalbn(0x1p+1023,-2097) should give 0x1p-1074, but the old code gave 0)
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D28872
(cherry picked from commit 760b2ffc55)
I did this without a full vendor update since that would cause too many
conflicts. Since these files now almost match the NetBSD sources the
next git subtree merge should work just fine.
Reviewed By: lwhsu
Differential Revision: https://reviews.freebsd.org/D28797
(cherry picked from commit 1ec3feb648)
This tests fork()s, so if there is still data in the stdout buffer on fork
it will print it again in the child process. This was happening in the
CheriBSD CI and caused the test to complain about malformed TAP output.
Reviewed By: ngie
Differential Revision: https://reviews.freebsd.org/D28397
(cherry picked from commit 892a05ee3a)
When using clang with x86_64 CPUs that support AVX, some floating point
transformations may raise exceptions that would not have been raised by
the original code. To avoid this, use the -fp-exception-behavior=maytrap
flag, introduced in clang 10.0.0.
In particular, this fixes a number of test failures with ctanhf(3) and
ctanf(3), when libm is compiled with -mavx. An unexpected FE_INVALID
exception is then raised, because clang emits vdivps instructions to
perform certain divides. (The vdivps instruction operates on multiple
single-precision float operands simultaneously, but the exceptions may
be influenced by unused parts of the XMM registers. In this particular
case, it was calculating 0 / 0, which results in FE_INVALID.)
If -fp-exception-behavior=maytrap is specified however, clang uses
vdivss instructions instead, which work on one operand, and should not
raise unexpected exceptions.
Reported by: olivier
Reviewed by: arichardson
PR: 254911
Differential Revision: https://reviews.freebsd.org/D29686
(cherry picked from commit 3b00222f15)
Only use -fp-exception-behavior=maytrap on x86, for now
After 3b00222f15, it turns out that clang only supports strict
floating point semantics for SystemZ and x86 at the moment, while for
other architectures it is still experimental.
Therefore, only use -fp-exception-behavior=maytrap on x86 for now,
otherwise this option results in "error: overriding currently
unsupported use of floating point exceptions on this target
[-Werror,-Wunsupported-floating-point-opt]" on other architectures.
Fixes: 3b00222f15
PR: 254911
(cherry picked from commit bae9fd0b33)
When compiling parts of math.h with clang using a C standard before C11,
and using -pedantic, it will result in warnings similar to:
bug254714.c:5:11: warning: '_Generic' is a C11 extension [-Wc11-extensions]
return !isfinite(1.0);
^
/usr/include/math.h:111:21: note: expanded from macro 'isfinite'
^
/usr/include/math.h:82:39: note: expanded from macro '__fp_type_select'
^
This is because the block that enables use of _Generic is conditional
not only on C11, but also on whether the compiler advertises support for
C generic selections via __has_extension(c_generic_selections).
To work around the warning without having to pessimize the code, use the
__extension__ keyword, which is supported by both clang and gcc. While
here, remove the check for __clang__, as _Generic has been supported for
a long time by gcc too now.
Reported by: yuri
PR: 254714
The man page says "The feenableexcept(), fedisableexcept(), and
fegetexcept() functions return a bitmap of the exceptions that were
unmasked prior to the call.", so we should return zero not -1.
Reviewed By: mhorne
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D29386
(cherry picked from commit dd5ed53a2f)
After increasing the lib/msun/tests WARNS to 6, this triggers a
compilation error for RISC-V.
Fixes: 87d65c747a ("lib/msun: Allow building tests with WARNS=6")
Reported by: Jenkins
(cherry picked from commit 15211f1950)
SVN r343917 fixed this for in-tree clang, but when building with a newer
out-of-tree clang the test was still marked as XFAIL.
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D28390
(cherry picked from commit 83ff5d5d98)
This applies musl commit b02eed9c4841913d690a2d0029737d72615384fe by
Szabolcs Nagy and updates the tests accordingly. This also allows
removing an XFAIL from the test.
musl commit message:
complex: fix ctanh(+-0+i*nan) and ctanh(+-0+-i*inf)
These cases were incorrect in C11 as described by
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1886.htm
PR: 217528
Reviewed By: dim
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28578
(cherry picked from commit a7b42c4b7f)
This forces the compiler to emit calls to libm functions, instead of
possibly substituting pre-calculated results at compile time, which
should help to actually test those functions.
Reviewed by: emaste, arichardson, ngie
Differential Revision: https://reviews.freebsd.org/D28577
(cherry picked from commit cf97d2a1da)
riscv: Add a soft-float implementation of fabs()
We could just use a C implementation using __builtin_fabs(), but using
this assembly version guarantees that there is no additional prolog/epilog
code. Additionally, clang generates worse code for masking off the top bit
than GCC: https://bugs.llvm.org/show_bug.cgi?id=49377.
This fixes the RISCV64 softfloat world build after cf97d2a1da. That commit
added -fno-builtin to the msun tests which resulted in the first references to
fabs (previously the compiler inlined all calls).
Reviewed By: dim
Reported by: mjg
Differential Revision: https://reviews.freebsd.org/D28994
(cherry picked from commit 524b018d20)
riscv: Fix whitespace issues in fabs added in 524b018d20
(cherry picked from commit 066dab17e7)
This adjusts the factor used to scale the subnormal numbers, so it
becomes the right value after adjusting its exponent. Thanks to Steve
Kargl for finding the most elegant fix.
Also enable the hypot tests, and add a test case for this bug.
PR: 253313
(cherry picked from commit d3338f3355)
Fix lib/msun/test builds on platforms without 80-bit long doubles
After d3338f3355, the lib/msun test case
'hypotl_near_underflow' would fail to compile on platforms where long
doubles weren't 80 bit, like on x86. Disable this particular test on
such platforms for now.
PR: 253313
(cherry picked from commit 2512066228)
This adjusts the check to trigger overflow/underflow to a slightly lower
value.
Before: powf(9.999995e-01, -1.342177e+08) -> inf
After: powf(9.999995e-01, -1.342177e+08) -> 1.858724e+31
(cherry picked from commit 93fc678965)
Add test case for 93fc678965 (incorrect powf(3) result)
This adds the test case to contrib/netbsd-tests/lib/libm/t_pow.c, as it
is currently the only place testing pow(3) and friends.
(cherry picked from commit 51af033287)
Reviewed By: lwhsu
Differential Revision: https://reviews.freebsd.org/D28396
(cherry picked from commit 4d2edf3af1)
Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10
This sprinkles a few strategic volatiles in an attempt to defeat clang's
optimization interfering with the expected floating-point exception
flags.
Reported by: lwhsu
PR: 244732
(cherry picked from commit ac76bc1145)
Follow-up to r353959 and r368070: do the same for other architectures.
arm32 already seems to use its own .fnstart/.fnend directives, which
appear to be ARM-specific variants of the same thing. Likewise, MIPS
uses .frame directives.
Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D27387
Some platforms have additional architecture-specific floating-point flags.
Msun test cases lrint and test_fegsetenv (fenv) expects only standard flags,
so make sure to mask them appropriately.
This makes test pass on PowerPC64.
Reviewed by: jhibbits, ngie
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D27202
Fix incorrect mask being used when FE_INVALID bit is wanted by user.
The problem was noticed thanks to msun fenv tests.
Reviewed by: jhibbits, luporl
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D27201
