#
0dd5a560 |
| 28-Jan-2024 |
Steve Kargl <kargl@FreeBSD.org> |
lib/msun: Cleanup after $FreeBSD$ removal
Remove no longer needed explicit inclusion of sys/cdefs.h.
PR: 276669 MFC after: 1 week
|
Revision tags: release/14.0.0 |
|
#
1d386b48 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
show more ...
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0 |
|
#
b7092eef |
| 19-Jul-2018 |
Bruce Evans <bde@FreeBSD.org> |
Fix spurious and extra underflows and resulting inaccuracies for some cases with 1 huge component and 1 tiny (but nowhere near denormal) component. Rescale earlier so that a scale factor of 2 can be
Fix spurious and extra underflows and resulting inaccuracies for some cases with 1 huge component and 1 tiny (but nowhere near denormal) component. Rescale earlier so that a scale factor of 2 can be combined with a non- scale divisor of 2, so that the division doesn't shift out a bit. In the usual case where the scale factor is just 1, the division may shift out a bit, but then the underflow is not spurious and the inaccuracies are harder to fix.
show more ...
|
#
50c8bd4e |
| 19-Jul-2018 |
Bruce Evans <bde@FreeBSD.org> |
Oops, r336412 undid the fix of the overflow threshold in r323003. Restore the previous overflow threshold and adjust comments.
|
#
1693fd03 |
| 17-Jul-2018 |
Bruce Evans <bde@FreeBSD.org> |
Minor cleanups to csqrt*(), mostly in comments.
Remove the STDC CX_LIMITED_RANGE pragma and its verbose comment. We still don't have any C99 compilers (that support fenv pragmas), and if we did the
Minor cleanups to csqrt*(), mostly in comments.
Remove the STDC CX_LIMITED_RANGE pragma and its verbose comment. We still don't have any C99 compilers (that support fenv pragmas), and if we did then there are thousands of other places in libm that would need to use them more than here.
The other cleanups are smaller.
show more ...
|
#
9d7dc136 |
| 17-Jul-2018 |
Bruce Evans <bde@FreeBSD.org> |
Fix scaling bugs which gave innaccuracies and spurious underflows in csqrt() and csqrtl().
When one component is huge and the other is tiny, scaling down the tiny component gave spurious underflow.
Fix scaling bugs which gave innaccuracies and spurious underflows in csqrt() and csqrtl().
When one component is huge and the other is tiny, scaling down the tiny component gave spurious underflow.
When both components are denormal, not scaling them up gave inaccuracies of 34+ ulps on not very carefully selected args. Fixing this reduces the maximum error to 1.6 ulps on the same set of args (mosly not denormal ones).
The scaling used multiplication of a complex variable by 2, but clang messes this on amd64 up by losing the sign of -0.0. Calculate the components separately, as is well known to be needed for operations on more exceptional values.
show more ...
|
#
6f1b8a07 |
| 17-Jul-2018 |
Bruce Evans <bde@FreeBSD.org> |
Add a macro nan_mix() and use it to get NaN results that are (bitwise) independent of the precision in most cases. This is mainly to simplify checking for errors. r176266 did this for e_pow[f].c us
Add a macro nan_mix() and use it to get NaN results that are (bitwise) independent of the precision in most cases. This is mainly to simplify checking for errors. r176266 did this for e_pow[f].c using a less refined expression that often didn't work. r176276 fixes an error in the log message for r176266. The main refinement is to always expand to long double precision. See old log messages (especially these 2) and the comment on the macro for more general details.
Specific details: - using nan_mix() consistently for the new and old pow*() functions was the only thing needed to make my consistency test for powl() vs pow() pass on amd64.
- catrig[fl].c already had all the refinements, but open-coded.
- e_atan2[fl].c, e_fmod[fl].c and s_remquo[fl] only had primitive NaN mixing.
- e_hypot[fl].c already had a different refined version of r176266. Refine this further. nan_mix() is not directly usable here since we want to clear the sign bit.
- e_remainder[f].c already had an earlier version of r176266.
- s_ccosh[f].c,/s_csinh[f].c already had a version equivalent to r176266. Refine this further. nan_mix() is not directly usable here since the expression has to handle some non-NaN cases.
- s_csqrt.[fl]: the mixing was special and mostly wrong. Partially fix the special version.
- s_ctanh[f].c already had a version of r176266.
show more ...
|
Revision tags: release/11.2.0 |
|
#
5e53a4f9 |
| 26-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
lib: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using mis-identified many licenses so this was mostly a manual - error pr
lib: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using mis-identified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
show more ...
|
Revision tags: release/10.4.0 |
|
#
b754c279 |
| 13-Sep-2017 |
Navdeep Parhar <np@FreeBSD.org> |
MFH @ r323558.
|
#
5be4ad9e |
| 09-Sep-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r323343
|
#
cf551d94 |
| 30-Aug-2017 |
Ryan Libby <rlibby@FreeBSD.org> |
lib/msun: avoid referring to broken LDBL_MAX
LDBL_MAX is broken on i386: https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html
Gcc has produced +Infinity for LDBL_MAX on i
lib/msun: avoid referring to broken LDBL_MAX
LDBL_MAX is broken on i386: https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html
Gcc has produced +Infinity for LDBL_MAX on i386 and amd64 with -m32 for some time, and newer versions of gcc are now warning that the "floating constant exceeds range of 'long double'". Avoid this by referring to proxy values instead.
Reviewed by: bde Approved by: markj (mentor) Sponsored by: Dell EMC Isilon
show more ...
|
#
4c889da8 |
| 12-Aug-2017 |
Ryan Libby <rlibby@FreeBSD.org> |
Revert r322418, LDBL_MAX_EXP unsuitable for macro pasting on some arches
Either need a different way to spell HALF_LDBL_MAX, or a different way to spell LDBL_MAX_EXP, or a different approach.
Repor
Revert r322418, LDBL_MAX_EXP unsuitable for macro pasting on some arches
Either need a different way to spell HALF_LDBL_MAX, or a different way to spell LDBL_MAX_EXP, or a different approach.
Reported by: ian
show more ...
|
#
9afac9fe |
| 12-Aug-2017 |
Ryan Libby <rlibby@FreeBSD.org> |
lib/msun: avoid referring to broken LDBL_MAX
LDBL_MAX is broken on i386: https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html
Gcc has produced +Infinity for LDBL_MAX on i
lib/msun: avoid referring to broken LDBL_MAX
LDBL_MAX is broken on i386: https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html
Gcc has produced +Infinity for LDBL_MAX on i386 and amd64 with -m32 for some time, and newer versions of gcc are now warning that the "floating constant exceeds range of 'long double'". Avoid this by referring to half the value of LDBL_MAX instead.
Reviewed by: bde Approved by: markj (mentor) Sponsored by: Dell EMC Isilon
show more ...
|
Revision tags: release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0 |
|
#
98e0ffae |
| 27-May-2015 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge sync of head
|
#
d899be7d |
| 19-Jan-2015 |
Glen Barber <gjb@FreeBSD.org> |
Reintegrate head: r274132-r277384
Sponsored by: The FreeBSD Foundation
|
#
8f0ea33f |
| 13-Jan-2015 |
Glen Barber <gjb@FreeBSD.org> |
Reintegrate head revisions r273096-r277147
Sponsored by: The FreeBSD Foundation
|
#
afbe8aa4 |
| 18-Dec-2014 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead @ r275911 (also, sort out MK_* flags in BMAKE, etc on this branch)
|
#
e65720e1 |
| 18-Dec-2014 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r275759 through r275911.
|
#
2cec876a |
| 16-Dec-2014 |
Ed Schouten <ed@FreeBSD.org> |
Rename cpack*() to CMPLX*().
The C11 standard introduced a set of macros (CMPLX, CMPLXF, CMPLXL) that can be used to construct complex numbers from a pair of real and imaginary numbers. Unfortunatel
Rename cpack*() to CMPLX*().
The C11 standard introduced a set of macros (CMPLX, CMPLXF, CMPLXL) that can be used to construct complex numbers from a pair of real and imaginary numbers. Unfortunately, they require some compiler support, which is why we only define them for Clang and GCC>=4.7.
The cpack() function in libm performs the same task as CMPLX(), but cannot be used to generate compile-time constants. This means that all invocations of cpack() can safely be replaced by C11's CMPLX(). To keep the code building with GCC 4.2, provide copies of CMPLX() that can at least be used to generate run-time complex numbers.
This makes it easier to build some of the functions outside of libm.
show more ...
|
Revision tags: release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0 |
|
#
65faab72 |
| 08-Aug-2008 |
David Schultz <das@FreeBSD.org> |
In the line #pragma STDC CX_LIMITED_RANGE ON the "ON" needs to be in caps. gcc doesn't understand this pragma anyway and assumes it is always on in any case, but icc supports it and cares about
In the line #pragma STDC CX_LIMITED_RANGE ON the "ON" needs to be in caps. gcc doesn't understand this pragma anyway and assumes it is always on in any case, but icc supports it and cares about the case.
show more ...
|
#
511dd36b |
| 30-Mar-2008 |
David Schultz <das@FreeBSD.org> |
Implement csqrtl().
|
Revision tags: release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0 |
|
#
65faab72 |
| 08-Aug-2008 |
David Schultz <das@FreeBSD.org> |
In the line #pragma STDC CX_LIMITED_RANGE ON the "ON" needs to be in caps. gcc doesn't understand this pragma anyway and assumes it is always on in any case, but icc supports it and cares about
In the line #pragma STDC CX_LIMITED_RANGE ON the "ON" needs to be in caps. gcc doesn't understand this pragma anyway and assumes it is always on in any case, but icc supports it and cares about the case.
show more ...
|
#
511dd36b |
| 30-Mar-2008 |
David Schultz <das@FreeBSD.org> |
Implement csqrtl().
|