#
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/
|
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 |
|
#
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, 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 |
|
#
209be205 |
| 16-May-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r317971 through r318379.
|
#
3a462c98 |
| 14-May-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Silence a -Wunused warning about the junk variable being used to raise an inexact floating point exception. The variable cannot be eliminated, unfortunately, otherwise the desired addition triggerin
Silence a -Wunused warning about the junk variable being used to raise an inexact floating point exception. The variable cannot be eliminated, unfortunately, otherwise the desired addition triggering the exception will be emitted neither by clang, nor by gcc.
Reviewed by: Steve Kargl, bde MFC after: 3 days
show more ...
|
#
a3906ca5 |
| 17-Feb-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r313644 through r313895.
|
#
a11c5077 |
| 15-Feb-2017 |
Mahdi Mokhtari <mmokhi@FreeBSD.org> |
Add casinl() cacosl() catanl() casinhl() cacoshl() catanhl() APIs to msun to improve C11 conformance.
PR: 216850 216851 216852 216856 216857 216858 Submitted by: mmokhi Reported by: sgk@troutmask.a
Add casinl() cacosl() catanl() casinhl() cacoshl() catanhl() APIs to msun to improve C11 conformance.
PR: 216850 216851 216852 216856 216857 216858 Submitted by: mmokhi Reported by: sgk@troutmask.apl.washington.edu Reviewed by: bde, mat, theraven Approved by: bde (src committer), mat (mentor) Differential Revision: https://reviews.freebsd.org/D9491
show more ...
|