#
334771 |
|
07-Jun-2018 |
dim |
MFC r334445:
Resolve conflicts between macros in fenv.h and ieeefp.h
This is a follow-up to r321483, which disabled -Wmacro-redefined for some lib/msun tests.
If an application included both fenv.h and ieeefp.h, several macros such as __fldcw(), __fldenv() were defined in both headers, with slightly different arguments, leading to conflicts.
Fix this by putting all the common macros in the machine-specific versions of ieeefp.h. Where needed, update the arguments in places where the macros are invoked.
This also slightly reduces the differences between the amd64 and i386 versions of ieeefp.h.
Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D15633
|
#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
226218 |
|
10-Oct-2011 |
das |
Provide external definitions of all of the standardized functions in fenv.h that are currently inlined.
The definitions are provided in fenv.c via 'extern inline' declaractions. This assumes the compiler handles 'extern inline' as specified in C99, which has been true under FreeBSD since 8.0.
The goal is to eventually remove the 'static' keyword from the inline definitions in fenv.h, so that non-inlined references all wind up pointing to the same external definition like they're supposed to. I am deferring the second step to provide a window where newly-compiled apps will still link against old math libraries. (This isn't supported, but there's no need to cause undue breakage.)
Reviewed by: stefanf, bde
|
#
143708 |
|
16-Mar-2005 |
das |
Replace fegetmask() and fesetmask() with feenableexcept(), fedisableexcept(), and fegetexcept(). These two sets of routines provide the same functionality. I implemented the former as an undocumented internal interface to make the regression test easier to write. However, fe(enable|disable|get)except() is already part of glibc, and I would like to avoid gratuitous differences. The only major flaw in the glibc API is that there's no good way to report errors on processors that don't support all the unmasked exceptions.
|