[PATCH]: PR29335 use MPFR for builtin sincos

Richard Guenther richard.guenther@gmail.com
Thu Nov 2 15:29:00 GMT 2006


On 11/2/06, Richard Guenther <richard.guenther@gmail.com> wrote:
> On 11/2/06, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> > On Wed, 1 Nov 2006, Roger Sayle wrote:
> >
> > > On Wed, 1 Nov 2006, Kaveh R. GHAZI wrote:
> > > > Is there any other testcase you would like me to try or can I install
> > > > the patch?
> > >
> > > The patch is OK for mainline.  It would also be nice if you could
> > > turn the sincos(zero,&s,&c) test case into something suitable for
> > > GCC's dejagnu testsuite and check that in.  And just for good luck
> > > perhaps something like:
> > >
> > > void foo(double x)
> > > {
> > >   double s, c;
> > >
> > >   if (x == 0.0)
> > >   {
> > >     sincos(x,&s,&c);
> > >     /* Check s and c.  */
> > >   }
> > > }
> > >
> > > However these new test cases can be committed as a follow-up patch.
> > > We've no reason to believe the tree-ssa passes can't handle the new
> > > non-gimple (*sp=X, *cp=Y) idiom that sincos folding can now produce,
> > > but it does no harm as to make sure things don't break in future.
> > >
> > > [I'll admit that I'm a bit curious as to which pass actually performs
> > > the simplification you tested for, but it'll be easy enough for me
> > > to investigate this for myself once your patch goes in. :-)]
> >
> > Sure I'll add some tests in a bit.  Two notes:
> >
> > 1.  In the case above, the simplification occurs only with both -O1 (or
> >     higher) and -ffast-math.  I'm not sure why -ffast-math is necessary.
> >
> > 2.  The simplification is not dependent on sincos or the pointer
> >     parameters.  E.g. if you replace sincos with sin(x) the same set of
> >     flags are necessary to enable the simplification.
>
> I believe this is just dom or one of the propagators being overly
> careful with not doing expression contraction (and so violating IEEE)
> without -funsafe-math-optimizations.
>
> Care to open a bugreport for this?

Not a bug.  It's DOM doing the propagation and it correctly does not
do it because (record_equivalence)

  /* For IEEE, -0.0 == 0.0, so we don't necessarily know the sign of a
     variable compared against zero.  If we're honoring signed zeros,
     then we cannot record this value unless we know that the value is
     nonzero.  */
  if (HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (x)))
      && (TREE_CODE (y) != REAL_CST
          || REAL_VALUES_EQUAL (dconst0, TREE_REAL_CST (y))))
    return;

and indeed, for 1.0 the propagation is happening even without -ffast-math.

Richard.



More information about the Gcc-patches mailing list