Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Use #include "fenv.h" instead of #include <fenv.h>. This makes it
more convenient to compile the math library by itself.

Requested by: bde

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

Use, in uncovered part, the END() macro in order to improve debugging.
In this specific case, Valgrind won't get confused when analyzing such
functions.

Sponsored by: Sandvine Incorporated
Tested by: emaste
MFC: 3 days

Use C comments since we now preprocess these files with CPP.

Add symbol versioning to libm.

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.

- Define the LDBL_PREC to be the number of significant bits in a long
double's mantissa.
- Add an assembly version of fmal.

Add an assembly version of fmal.

Work around a gcc bug. This fixes feholdexcept() et al. at -O1.
Symptoms of the problem included assembler warnings and
nondeterministic runtime behavior when a fe*() call that affects the
fpsr is closely followed by a float point op.

The bug (at least, I think it's a bug) is that gcc does not insert a
break between a volatile asm and a dependent instruction if the
volatile asm came from an inlined function. Volatile asms seem to be
fine in other circumstances, even without -mvolatile-asm-stop, so
perhaps the compiler adds the stop bits before inlining takes place.
The problem does not occur at -O0 because inlining is disabled, and it
doesn't happen at -O2 because -fschedule-insns2 knows better.

Move machine-dependent crud to its own makefile.

Add fma() and fmaf(), which implement a fused multiply-add operation.

Mark all inline asms that read the floating-point control or status
registers as volatile. Instructions that *wrote* to FP state were
already marked volatile, but apparently gcc has license to move
non-volatile asms past volatile asms. This broke amd64's feupdateenv
at -O2 due to a WAR conflict between fnstsw and fldenv there.

Shift the FPSR contents by the correct amount so feupdateenv() raises
the correct exceptions from the old environment.

Add an fenv.h implementation for the ia64 port.

Reviewed by: standards@