Don't rely on sys/_types.h including sys/cdefs.h

These headers relied in __BEGIN_DECS/__END_DECLS being defined when
sys/_types.h was included, but there's not a requirement that this be
the case.

Don't rely on sys/_types.h including sys/cdefs.h

These headers relied in __BEGIN_DECS/__END_DECLS being defined when
sys/_types.h was included, but there's not a requirement that this be
the case.

Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595

show more ...

math.h: Remove support for old gcc versions

Remove support for old gcc versions by unconditionally defining
__MATH_BUILTIN_RELOPS and __MATH_BUILTIN_CONSTANTS. Per kib's request,
don't #undef those

math.h: Remove support for old gcc versions

Remove support for old gcc versions by unconditionally defining
__MATH_BUILTIN_RELOPS and __MATH_BUILTIN_CONSTANTS. Per kib's request,
don't #undef those so it's easier to understand what the builtins are
doing.

Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D45655
Sponsored by: Netflix

show more ...

math: Add long double constant definitions

These constants are GNU libc extensions that are likely to be adopted
by the next POSIX revision [1]. The definitions can be verified in
a PARI-GP shell se

math: Add long double constant definitions

These constants are GNU libc extensions that are likely to be adopted
by the next POSIX revision [1]. The definitions can be verified in
a PARI-GP shell session:

* M_El: exp (1)
* M_LOG2El: log (exp (1)) / log (2)
* M_LOG10El: log (exp (1)) / log (10)
* M_LN2l: log (2)
* M_LN10l: log (10)
* M_PIl: Pi
* M_PI_2l: Pi / 2
* M_PI_4l: Pi / 4
* M_1_PIl: 1 / Pi
* M_2_PIl: 2 / Pi
* M_2_SQRTPIl: 2 / sqrt (Pi)
* M_SQRT2l: sqrt (2)
* M_SQRT1_2l: 1 / sqrt (2)

[1] https://austingroupbugs.net/view.php?id=828

Put these behind __BSD_VISIBLE || __XSI_VISIBLE >= 800 to future-proof
these changes. They shouldn't be defined at lower levels of XSI, but don't
have other XSI 800 stuff in place yet.

Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Reviewed by: imp, allanjude
Pull Request: https://github.com/freebsd/freebsd-src/pull/1121

show more ...

include/math.h: fix warning with -Wconversion

The way the __fp_type_select macro uses the _Generic expression causes
gcc to throw a warning on valid code if the -Wconversion flag is used.

For examp

include/math.h: fix warning with -Wconversion

The way the __fp_type_select macro uses the _Generic expression causes
gcc to throw a warning on valid code if the -Wconversion flag is used.

For example, consider the following program:

#include <math.h>
int main()
{
double x = 1.0;
isnan(x);
return 0;
}

which throws a warning:

$ gcc -Wconversion a.c
a.c:5:15: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion]
5 | isnan(x);
| ^

This happens because the functions are invoked inside of the _Generic.
Looking at the example of _Generic in the C11 specification, one sees
that the parameters are outside of the _Generic expression (see page 79
here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf).

Reference: https://stackoverflow.com/a/68309379
Signed-off-by: Martin Oliveira <martin.oliveira@eideticom.com>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/841

show more ...

lib/msun: Cleanup after $FreeBSD$ removal

Remove no longer needed explicit inclusion of sys/cdefs.h.

PR: 276669
MFC after: 1 week

lib: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl s

lib: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...

math: Move to const instead of __const

There's no reason to use the __const construct here. This is a left-over
from supporting K&R and ANSI compilers in the original Sun msun. All
other K&R crutche

math: Move to const instead of __const

There's no reason to use the __const construct here. This is a left-over
from supporting K&R and ANSI compilers in the original Sun msun. All
other K&R crutches have been removed. Remove these as well. There's no
semantic difference. And there's already several others in math.h.

Sponsored by: Netflix

show more ...

Remove $FreeBSD$: one-line .h pattern

Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/

Remove unnecessary const and volatile qualifiers from __fp_type_select()

Since https://github.com/llvm/llvm-project/commit/ca75ac5f04f2, clang 15
has a new warning about _Generic selection expressio

Remove unnecessary const and volatile qualifiers from __fp_type_select()

Since https://github.com/llvm/llvm-project/commit/ca75ac5f04f2, clang 15
has a new warning about _Generic selection expressions, such as used in
math.h:

lib/libc/gdtoa/_ldtoa.c:82:10: error: due to lvalue conversion of the controlling expression, association of type 'volatile float' will never be selected because it is qualified [-Werror,-Wunreachable-code-generic-assoc]
switch (fpclassify(u.e)) {
^
lib/msun/src/math.h:109:2: note: expanded from macro 'fpclassify'
__fp_type_select(x, __fpclassifyf, __fpclassifyd, __fpclassifyl)
^
lib/msun/src/math.h:85:14: note: expanded from macro '__fp_type_select'
volatile float: f(x), \
^

This is because the controlling expression always undergoes lvalue
conversion first, dropping any cv-qualifiers. The 'const', 'volatile',
and 'volatile const' associations will therefore never be used.

MFC after: 1 week
Reviewed by: theraven
Differential Revision: https://reviews.freebsd.org/D35815

show more ...

[LIBM] implementations of sinpi[fl], cospi[fl], and tanpi[fl]

Both IEEE-754 2008 and ISO/IEC TS 18661-4 define the half-cycle
trignometric functions cospi, sinpi, and tanpi. The attached
patch impl

[LIBM] implementations of sinpi[fl], cospi[fl], and tanpi[fl]

Both IEEE-754 2008 and ISO/IEC TS 18661-4 define the half-cycle
trignometric functions cospi, sinpi, and tanpi. The attached
patch implements cospi[fl], sinpi[fl], and tanpi[fl]. Limited
testing on the cospi and sinpi reveal a max ULP less than 0.89;
while tanpi is more problematic with a max ULP less than 2.01
in the interval [0,0.5]. The algorithms used in these functions
are documented in {ks}_cospi.c, {ks}_sinpi.c, and s_tanpi.c.

Note. I no longer have access to a system with ld128 and
adequate support to compile and test the ld128 implementations
of these functions. Given the almost complete lack of input from
others on improvements to libm, I doubt that anyone cares. If
someone does care, the ld128 files contain a number of FIXME comments,
and in particular, while the polynomial coefficients are given
I did not update the polynomial algorithms to properly use the
coefficients.

PR: 218514
MFC after: 2 weeks

show more ...

Avoid -pedantic warnings about using _Generic in __fp_type_select

When compiling parts of math.h with clang using a C standard before C11,
and using -pedantic, it will result in warnings similar to:

Avoid -pedantic warnings about using _Generic in __fp_type_select

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
MFC after: 1 week

show more ...

Remove intel compiler support from math.h

The intel compiler support has badly decayed over the years. Stop
pretending that we support it. Note, I've stopped short of requiring
gcc builtin support w

Remove intel compiler support from math.h

The intel compiler support has badly decayed over the years. Stop
pretending that we support it. Note, I've stopped short of requiring
gcc builtin support with this commit since other compilers may be used
to build non-base software and we need to support those so more
investigation is needed before simplifying further.

show more ...

Add __isnan()/__isnanf() aliases for compatibility with glibc and CUDA

Even though clang comes with a number of internal CUDA wrapper headers,
compiling sample CUDA programs will result in errors si

Add __isnan()/__isnanf() aliases for compatibility with glibc and CUDA

Even though clang comes with a number of internal CUDA wrapper headers,
compiling sample CUDA programs will result in errors similar to:

In file included from <built-in>:1:
In file included from /usr/lib/clang/9.0.0/include/__clang_cuda_runtime_wrapper.h:204:
/usr/home/arr/cuda/var/cuda-repo-10-0-local-10.0.130-410.48/usr/local/cuda-10.0//include/crt/math_functions.hpp:2910:7: error: no matching function for call to '__isnan'
if (__isnan(a)) {
^~~~~~~
/usr/lib/clang/9.0.0/include/__clang_cuda_device_functions.h:460:16: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ int __isnan(double __a) { return __nv_isnand(__a); }
^

CUDA expects __isnan() and __isnanf() declarations to be available,
which are glibc specific extensions, equivalent to the regular isnan()
and isnanf().

To provide these, define __isnan() and __isnanf() as aliases of the
already existing static inline functions __inline_isnan() and
__inline_isnanf() from math.h.

Reported by: arrowd
PR: 241550
MFC after: 1 week

show more ...

Merge ^/head r318964 through r319164.

Implement sincos, sincosf, and sincosl.
The primary benefit of these functions is that argument
reduction is done once instead of twice in independent
calls to sin() and cos().

* lib/msun/Makefile:

Implement sincos, sincosf, and sincosl.
The primary benefit of these functions is that argument
reduction is done once instead of twice in independent
calls to sin() and cos().

* lib/msun/Makefile:
. Add s_sincos[fl].c to the build.
. Add sincos.3 documentation.
. Add appropriate MLINKS.

* lib/msun/Symbol.map:
. Expose sincos[fl] symbols in dynamic libm.so.

* lib/msun/man/sincos.3:
. Documentation for sincos[fl].

* lib/msun/src/k_sincos.h:
. Kernel for sincos() function. This merges the individual kernels
for sin() and cos(). The merger offered an opportunity to re-arrange
the individual kernels for better performance.

* lib/msun/src/k_sincosf.h:
. Kernel for sincosf() function. This merges the individual kernels
for sinf() and cosf(). The merger offered an opportunity to re-arrange
the individual kernels for better performance.

* lib/msun/src/k_sincosl.h:
. Kernel for sincosl() function. This merges the individual kernels
for sinl() and cosl(). The merger offered an opportunity to re-arrange
the individual kernels for better performance.

* lib/msun/src/math.h:
. Add prototytpes for sincos[fl]().

* lib/msun/src/math_private.h:
. Add RETURNV macros. This is needed to reset fpsetprec on I386
hardware for a function with type void.

* lib/msun/src/s_sincos.c:
. Implementation of sincos() where sin() and cos() were merged into
one routine and possibly re-arranged for better performance.

* lib/msun/src/s_sincosf.c:
. Implementation of sincosf() where sinf() and cosf() were merged into
one routine and possibly re-arranged for better performance.

* lib/msun/src/s_sincosl.c:
. Implementation of sincosl() where sinl() and cosl() were merged into
one routine and possibly re-arranged for better performance.

PR: 215977, 218300
Submitted by: Steven G. Kargl <sgk@troutmask.apl.washington.edu>
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D10765

show more ...

Fix frexpl() declaration to not include the field name.

MFC after: 1 month

Merge from head@274682

Sync to HEAD@r272516.

IFC @r271694

* Makefile:
. Hook e_lgammal[_r].c to the build.
. Create man page links for lgammal[-r].3.

* Symbol.map:
. Sort lgammal to its rightful place.
. Add FBSD_1.4 section for the new lgamal_r sy

* Makefile:
. Hook e_lgammal[_r].c to the build.
. Create man page links for lgammal[-r].3.

* Symbol.map:
. Sort lgammal to its rightful place.
. Add FBSD_1.4 section for the new lgamal_r symbol.

* ld128/e_lgammal_r.c:
. 128-bit implementataion of lgammal_r().

* ld80/e_lgammal_r.c:
. Intel 80-bit format implementation of lgammal_r().

* src/e_lgamma.c:
. Expose lgammal as a weak reference to lgamma for platforms
where long double is mapped to double.

* src/e_lgamma_r.c:
. Use integer literal constants instead of real literal constants.
Let compiler(s) do the job of conversion to the appropriate type.
. Expose lgammal_r as a weak reference to lgamma_r for platforms
where long double is mapped to double.

* src/e_lgammaf_r.c:
. Fixed the Cygnus Support conversion of e_lgamma_r.c to float.
This includes the generation of new polynomial and rational
approximations with fewer terms. For each approximation, include
a comment on an estimate of the accuracy over the relevant domain.
. Use integer literal constants instead of real literal constants.
Let compiler(s) do the job of conversion to the appropriate type.
This allows the removal of several explicit casts of double values
to float.

* src/e_lgammal.c:
. Wrapper for lgammal() about lgammal_r().

* src/imprecise.c:
. Remove the lgamma.

* src/math.h:
. Add a prototype for lgammal_r().

* man/lgamma.3:
. Document the new functions.

Reviewed by: bde

show more ...

IFC @r269962

Submitted by: Anish Gupta (akgupt3@gmail.com)

Merge head from 7/28

Sync to HEAD@r269943.

When r255294 was committed, it exposed the symbols lgammal, powl,
and tgammal in libm. These functions are part of ISO/IEC 9899:1999
and their prototypes should have been moved into the appropriate

When r255294 was committed, it exposed the symbols lgammal, powl,
and tgammal in libm. These functions are part of ISO/IEC 9899:1999
and their prototypes should have been moved into the appropriate
__ISO_C_VISIBLE >= 1999 section. After moving the prototypes,
remnants of r236148 can be removed.

PR: standards/191754
Reviewed by: bde

show more ...

* Makefile:
. Add s_erfl.c to building libm.
. Add MLINKS for erfl.3 and erfcl.3.

* Symbol.map:
. Move erfl and erfcl to their proper location.

* ld128/s_erfl.c:
. Implementations of erfl a

* Makefile:
. Add s_erfl.c to building libm.
. Add MLINKS for erfl.3 and erfcl.3.

* Symbol.map:
. Move erfl and erfcl to their proper location.

* ld128/s_erfl.c:
. Implementations of erfl and erfcl in the IEEE 754 128-bit format.

* ld80/s_erfl.c:
. Implementations of erfl and erfcl in the Intel 80-bit format.

* man/erf.3:
. Document the new functions.
. While here, remove an incomplete sentence.

* src/imprecise.c:
. Remove the stupidity of mapping erfl and erfcl to erf and erfc.

* src/math.h:
. Move the declarations of erfl and erfcl to their proper place.

* src/s_erf.c:
. For architectures where double and long double are the same
floating point format, use weak references to map erfl to
erf and ercl to erfc.

Reviewed by: bde (many earlier versions)

show more ...