This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: PR29335 use MPFR for more math builtins
- From: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 25 Oct 2006 16:55:32 -0400 (EDT)
- Subject: Re: [PATCH]: PR29335 use MPFR for more math builtins
- References: <Pine.LNX.firstname.lastname@example.org>
On Wed, 25 Oct 2006, Roger Sayle wrote:
> On Wed, 25 Oct 2006, Kaveh R. GHAZI wrote:
> > 2006-10-25 Kaveh R. Ghazi <email@example.com>
> > PR middle-end/29335
> > * builtins.c (fold_builtin_cbrt, fold_builtin_logarithm):
> > Calculate compile-time constants using MPFR.
> > (fold_builtin_1): Likewise handle BUILT_IN_ERF, BUILT_IN_ERFC,
> > BUILT_IN_EXPM1 and BUILT_IN_LOG1P.
> > testsuite:
> > * gcc.dg/torture/builtin-math-2.c (TESTIT): Use new helper macro.
> > Add checks for log, log2, log10 and log1p.
> > * gcc.dg/torture/builtin-math-3.c: Add checks for -0.0 everywhere
> > we already test 0.0. Add checks for expm1, log, log2, log10,
> > log1p, cbrt, erf and erfc.
> This is OK for mainline.
> But a minor style nit:
> > - tree arg = TREE_VALUE (arglist);
> > + tree arg = TREE_VALUE (arglist), res;
> My personal preference would be to write this as either
> tree arg = TREE_VALUE (arglist);
> tree res;
> tree res, arg = TREE_VALUE (arglist);
> The rational is that the definition of variables can get obscured by
> large (potentially multi-line) initializers. I try to stick with the
> rule of thumb that if a C variable has an initialization, it should
> appear in it's own declaration. However, given it's a style choice,
> I can appreciate other folks preferring the second form, placing things
> on one line, but with an initializer last. Does anyone have a strong
> opinion on this?
I used the two-line form per Eric C's offline email. I also went back and
converted the other couple of instances from previous patches.
> Thanks again for adding support for these functions. I know some
> fortran folks at Los Alamos that'll be happy to see improved support
> for "erf" and "erfc".
You're welcome, thanks for the review. BTW, I don't know if fortran will
benefit automatically from my work as I don't know that it uses the
builtins directly. But this stuff probably makes it easier if the fortran
maintainers are so inclined. :-)
Kaveh R. Ghazi firstname.lastname@example.org