This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 2.95 and floating point precision
- To: craig at jcb-sc dot com, hazeghi at 2xtreme dot net
- Subject: Re: GCC 2.95 and floating point precision
- From: N8TM at aol dot com
- Date: Sun, 8 Aug 1999 10:22:39 EDT
- CC: toon at moene dot indiv dot nluug dot nl, gcc at gcc dot gnu dot org
In a message dated 8/8/99 4:47:10 AM PST, craig@jcb-sc.com writes:
> the bug is in your code, and, as is so often
> the case, you're complaining about gcc exposing it by optimizing it
> sufficiently to expose the bug.
I've been seeing what may be a similar situation: Elefunt (Plauger's C
version) is reporting a loss of 9 bits (relative to expected 53) for exp()
and 6 bits for pow() when compiled with optimization in gcc-2.95 on cygwin.
There is no such problem with expl() and powl() (relative to expected 64 bit
precision), nor is there a problem without optimization. The problem goes
away on my linux/libc6 installation although I expect it could be replicated
with careful disabling of the MATH_INLINE feature.
Speaking of libc6, several of the long double math functions are inadequate
(even pow() shows some failures), and even more unpredictable results may be
provoked by the in-lining feature in C. Maybe we don't want to open that can
of worms in g77 (except for pow(), which is biting us already)!
Tim
tprince@computer.org