Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3 |
|
#
404c8a26 |
| 31-Aug-2019 |
Sascha Wildner <saw@online.de> |
cdefs.h/libm: Add __sym_{compat,default}() helper macros and use in libm.
While here, change the "past<function>" naming scheme to "past_<function>" like it is already for "weak_" and "imprecise_" c
cdefs.h/libm: Add __sym_{compat,default}() helper macros and use in libm.
While here, change the "past<function>" naming scheme to "past_<function>" like it is already for "weak_" and "imprecise_" cases.
Macros-taken-from: FreeBSD
show more ...
|
Revision tags: v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc, v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1, v4.8.1, v4.8.0, v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0, v4.4.3, v4.4.2, v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1 |
|
#
be0c75e8 |
| 13-Jul-2015 |
John Marino <draco@marino.st> |
Replace hybrid libm with OpenBSD libm on vendor branch
In order to gain full c++11 support on GCC, we had to import a number of long double functions from NetBSD, once again converting libm into a h
Replace hybrid libm with OpenBSD libm on vendor branch
In order to gain full c++11 support on GCC, we had to import a number of long double functions from NetBSD, once again converting libm into a hybrid library from a mixture of sources. As of today, FreeBSD still doesn't have the missing functions and the PR on broken c++11 has been lingering for months.
The OpenBSD libm is complete and maintained[1][2]. It's unmodified sources are in vendor/OPENBSD_LIBM branch with local modifications (to squelch gcc warnings and adjust for OS differences mainly) are applied to the master for easy diff generation.
A dports bulk build was executing using the new math library and the result is the ports built normally.
[1] The final two "imprecise" functions were replaced by proper long double versions. The imprecise versions remain as older symbols (libm has symbol versioning) so this source is additional to what is provided in the vendor branch. (powl, tgammal)
[2] There were several DF306.0 symbols that are not present in OpenLIBM, partially because they've been moved to libc or were always there. In order to maintain backwards capability, copies of these functions with new names are built into libm, and given DF306.0 versions only. Without the version suffix, these past functions will not link to new programs.
show more ...
|
Revision tags: v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc, v4.0.5, v4.0.4, v4.0.3, v4.0.2 |
|
#
2fedfd5c |
| 29-Nov-2014 |
John Marino <draco@marino.st> |
libm: Sync with FreeBSD (gains 6 long double functions)
The following functions have been implemented: - coshl - erfcl - erfl - lgammal - sinhl - tanhl
Before these were approximated wi
libm: Sync with FreeBSD (gains 6 long double functions)
The following functions have been implemented: - coshl - erfcl - erfl - lgammal - sinhl - tanhl
Before these were approximated with the double versions using the "imprecise" macros. I've left the old ones in place (unlike FreeBSD) but with symbol versioning so that libraries built with the earlier versions can link to them. In other words, there are two versions of these 6 functions, Df306.1 and DF402.0.
show more ...
|
Revision tags: v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0 |
|
#
967141b1 |
| 29-Sep-2013 |
John Marino <draco@marino.st> |
libm: Update erf, add imprecise versions of missing c++11 functions
Provide updates to erf and erff functions.
Also add weak versions of the missing c++11 long double functions by using taking argu
libm: Update erf, add imprecise versions of missing c++11 functions
Provide updates to erf and erff functions.
Also add weak versions of the missing c++11 long double functions by using taking arguments of type double. Use of these versions will result in a linker warning to discourage program that really need extra precision from using them.
Note that since the c/c++ specs only guarantee that long double has precision equal to double, code that relies on these functions having greater precision is unportable at best and broken at worst.
Taken-from: FreeBSD
show more ...
|