[PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax

[Andrew Pinski]

> 
> 
> On Tue, 7 Nov 2006, Kaveh R. GHAZI wrote:
> > 2006-11-04  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
> >
> > 	* builtins.c (do_mpfr_arg3): New.
> > 	(fold_builtin_1): Handle builtins fma, fmin and fmax.
> >
> > testsuite:
> > 	* gcc.dg/torture/builtin-math-2.c: Test builtin fma.
> > 	* gcc.dg/torture/builtin-math-3.c (CKSGN_F, CKSGN, CKSGN_L):
> > 	New macros. Use them in exact tests.
> > 	(TESTIT3): New macro.
> > 	Add tests for fmin, fmax and fma.
> 
> This is OK for mainline.  Thanks.
> 
> I'm not exactly sure what the official middle-end position on
> min(0.0,-0.0) and max(0.0,-0.0) is.  I know that Java requires
> the sign to be taken into consideration, but I'm unsure whether
> we require this of the backend-provided min?f3/max?f3 optabs or
> of the RTL we expand if a min/max optab isn't available.  I've
> not checked but I've a suspicion that we generate a<b?a:b, and
> therefore obtain an arbitrary sign.

Java has already been moved away from using MIN/MAX_EXPR. See PR
25676.

tree.def says:
/* Minimum and maximum values.  When used with floating point, if both
   operands are zeros, or if either operand is NaN, then it is unspecified
   which of the two operands is returned as the result.  */

Which means to me zero and negative zero are handled as zero which is why Java
moved away from using MIN/MAX_EXPR.

Thanks,
Andrew Pinski