This is the mail archive of the gcc@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: Sine and Cosine Accuracy


Richard Henderson wrote:
> On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote:
> 
>>I've never quite understood the necessity for performing trig operations
>>on excessively large values, but perhaps my problem domain hasn't
>>included such applications.
> 
> 
> Whether you think it necessary or not, the ISO C functions allow
> such arguments, and we're not allowed to break that without cause.

Then, as someone else said, why doesn't the compiler enforce -ansi
and/or -pedantic by default? Or is ANSI purity only important in some
cases, but not others?

I do not and have not suggested changing the default behavior of the
compiler, and *have* suggested that it is not pedantic enough about
Standards.

*This* discussion is about improving -funsafe-math-optimizations to make
it more sensible and flexible.

For a wide variety of applications, the hardware intrinsics provide both
faster and more accurate results, when compared to the library
functions. However, I may *not* want other transformations implied by
-funsafe-math-optimizations. Therefore, it seems to me that GCC could
cleanly and simply implement an option to use hardware intrinsics (or a
highly-optimized but non-ANSI library) for those of us who want it.

No changes to default optimizations, no breaking of existing code, just
a new option (as in optional.)

How does that hurt you or anyone else? It's not as if GCC doesn't have a
few options already... ;)

I (and others) also note other compilers do a fine job of handling these
problems.

..Scott


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