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: weird optimization in sin+cos, x86 backend

On 2012-02-03 17:44:21 +0100, Michael Matz wrote:
> Hi,
> On Fri, 3 Feb 2012, Vincent Lefevre wrote:
> > > > For the glibc, I've finally reported a bug here:
> > > > 
> > > >
> > > 
> > > That is about 1.0e22, not the obscene 4.47460300787e+182 of the 
> > > original poster.
> > 
> > But 1.0e22 cannot be handled correctly.
> I'm not sure what you're getting at.  Yes, 1e22 isn't handled correctly, 
> but this thread was about 4.47460300787e+182 until you changed topics.

No, the topic is: "weird optimization in sin+cos, x86 backend".
But actually, as said by Richard Guenther, the bug is not the
optimization, but the behavior of the sincos function. What I'm
saying is that this wrong behavior can also be seen on 1.0e22
(at least with the glibc, and any implementation that uses the
fsincos x86 instruction).

> > > If you want to have precise numbers use an arbitrary precision math 
> > > library.
> > 
> > This is double precision. An arbitrary precision math library (even 
> > though I develop one) shouldn't be needed.
> But the reduction step needs much more precision than it currently uses to 
> handle inputs as large as 4e182 correctly.

No, the range reduction can cleverly be done using the working
precision (such as with Payne and Hanek's algorithm).

Vincent Lefèvre <> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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