This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: roger at eyesopen dot com (Roger Sayle)
- Cc: ghazi at caip dot rutgers dot edu (Kaveh R. GHAZI), gcc-patches at gcc dot gnu dot org
- Date: Thu, 9 Nov 2006 23:05:41 -0500 (EST)
- Subject: Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax
> On Tue, 7 Nov 2006, Kaveh R. GHAZI wrote:
> > 2006-11-04 Kaveh R. Ghazi <firstname.lastname@example.org>
> > * 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
/* 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.