Revision tags: release/14.0.0 |
|
#
b3e76948 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\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, 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, 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 |
|
#
ad5e21e2 |
| 07-Aug-2008 |
David Schultz <das@FreeBSD.org> |
Use cpack() and the gcc extension __imag__ to implement cimag() and conj() instead of using expressions like z * I. The latter is bad for several reasons:
1. It is implemented using arithmetic, whic
Use cpack() and the gcc extension __imag__ to implement cimag() and conj() instead of using expressions like z * I. The latter is bad for several reasons:
1. It is implemented using arithmetic, which is unnecessary, and can generate floating point exceptions, contrary to the requirements on these functions.
2. gcc implements complex multiplication using a formula that breaks down for infinities, e.g., it gives INFINITY * I == nan + inf I.
show more ...
|
Revision tags: release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0 |
|
#
8b5cd5a6 |
| 30-May-2004 |
Stefan Farfeleder <stefanf@FreeBSD.org> |
Add implementations for cimag{,f,l}, creal{,f,l} and conj{,f,l}. They are needed for cases where GCC's builtin functions cannot be used and for compilers that don't know about them.
Approved by: da
Add implementations for cimag{,f,l}, creal{,f,l} and conj{,f,l}. They are needed for cases where GCC's builtin functions cannot be used and for compilers that don't know about them.
Approved by: das (mentor)
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 |
|
#
ad5e21e2 |
| 07-Aug-2008 |
David Schultz <das@FreeBSD.org> |
Use cpack() and the gcc extension __imag__ to implement cimag() and conj() instead of using expressions like z * I. The latter is bad for several reasons:
1. It is implemented using arithmetic, whic
Use cpack() and the gcc extension __imag__ to implement cimag() and conj() instead of using expressions like z * I. The latter is bad for several reasons:
1. It is implemented using arithmetic, which is unnecessary, and can generate floating point exceptions, contrary to the requirements on these functions.
2. gcc implements complex multiplication using a formula that breaks down for infinities, e.g., it gives INFINITY * I == nan + inf I.
show more ...
|
Revision tags: release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0 |
|
#
8b5cd5a6 |
| 30-May-2004 |
Stefan Farfeleder <stefanf@FreeBSD.org> |
Add implementations for cimag{,f,l}, creal{,f,l} and conj{,f,l}. They are needed for cases where GCC's builtin functions cannot be used and for compilers that don't know about them.
Approved by: da
Add implementations for cimag{,f,l}, creal{,f,l} and conj{,f,l}. They are needed for cases where GCC's builtin functions cannot be used and for compilers that don't know about them.
Approved by: das (mentor)
show more ...
|