History log of /freebsd/lib/msun/src/s_csqrtl.c (Results 1 – 24 of 24)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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().