Move tests of fma from libm-test.inc to auto-libm-test-in.

This patch moves tests of fma to auto-libm-test-in, adding the
required support to gen-auto-libm-tests.

Because fma can have exact zero results depending on the rounding
mode, results of fma cannot always be determined from a single value
computed in higher precision with a sticky bit.  Thus, this patch adds
support for recomputing results with the original MPFR/MPC function in
the case where an exact zero is involved.  (This also affects some
results for cpow; when we start testing cpow in all rounding modes, I
think it will be most appropriate to make those tests use
IGNORE_ZERO_INF_SIGN, since ISO C does not attempt to determine signs
of zero results, or special caes in general, for cpow, and I think
signs of zero for cpow are beyond the scope of glibc's accuracy
goals.)

Simply treating the existing test inputs for fma like those for other
functions (i.e., as representing the given value rounded up or down to
any of the supported floating-point formats) increases the size of
auto-libm-test-out by about 16MB (i.e., about half the file is fma
test data).  While rounded versions of tests are perfectly reasonable
test inputs for fma, in this case having them seems excessive, so this
patch allows functions to specify in gen-auto-libm-tests that the
given test inputs are only to be interpreted exactly, not as
corresponding to values rounded up and down.  This reduces the size of
the generated test data for fma to a more reasonable 2MB.

A consequence of this patch is that fma is now tested for correct
presence or absence of "inexact" exceptions, where previously this
wasn't tested because I didn't want to try to add that test coverage
manually to all the existing tests.  As far as I know, the existing
fma implementations are already correct in this regard.

This patch provides the first cases where the gen-auto-libm-tests
support for distinguishing before-rounding/after-rounding underflow
actually produces separate entries in auto-libm-test-out (for
functions without exactly determined results, the affected cases are
all considered underflow-optional, so this only affects functions like
fma with exactly determined results).  I didn't see any signs of
problems with this logic in the output.

Tested x86_64 and x86.

	* math/auto-libm-test-in: Add tests of fma.
	* math/auto-libm-test-out: Regenerated.
	* math/libm-test.inc (fma_test_data): Use AUTO_TESTS_fff_f.
	(fma_towardzero_test_data): Likewise.
	(fma_downward_test_data): Likewise.
	(fma_upward_test_data): Likewise.
	* math/gen-auto-libm-tests.c (rounding_mode_desc): Add field
	mpc_mode.
	(rounding_modes): Add values for new field.
	(func_calc_method): Add value mpfr_fff_f.
	(func_calc_desc): Add mpfr_fff_f union field.
	(test_function): Add field exact_args.
	(FUNC): Add macro argument EXACT_ARGS.
	(FUNC_mpfr_f_f): Update call to FUNC.
	(FUNC_mpfr_f_f): Likewise.
	(FUNC_mpfr_ff_f): Likewise.
	(FUNC_mpfr_if_f): Likewise.
	(FUNC_mpc_c_f): Likewise.
	(FUNC_mpc_c_c): Likewise.
	(test_functions): Add fma.  Update calls to FUNC.
	(handle_input_arg): Add argument exact_args.
	(add_test): Update call to handle_input_arg.
	(calc_generic_results): Add argument mode.  Handle mpfr_fff_f.
	(output_for_one_input_case): Update call to calc_generic_results.
	Recalculate exact zero results in each rounding mode.

0 files changed, 0 insertions, 0 deletions