This is the mail archive of the 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 builtin sincos

On 11/2/06, Richard Guenther <> wrote:
On 11/2/06, Kaveh R. GHAZI <> 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.  */
     && (TREE_CODE (y) != REAL_CST
         || REAL_VALUES_EQUAL (dconst0, TREE_REAL_CST (y))))

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


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