This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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  <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.

Anyone have any opinions?  I suspect that we may require different
semantics for the MIN_EXPR/MAX_EXPRs that we recognize via fold
and/or ifcvt.c, than we do for explicit calls to fmin/fmax.
For example, with a<b?a:b, we're not symmetric min(x,y) !== min(y,x).
At least, everything comes out OK when using -ffast-math! :-)

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]