[PATCH] Evaluate pow(x,n) at compile-time
Geoff Keating
geoffk@geoffk.org
Mon Apr 14 20:16:00 GMT 2003
> Date: Mon, 14 Apr 2003 10:17:53 -0400 (EDT)
> From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
> Cc: gcc-patches@gcc.gnu.org, roger@eyesopen.com
> X-OriginalArrivalTime: 14 Apr 2003 14:18:00.0662 (UTC) FILETIME=[A7951F60:01C30290]
>
> > That's on x86, where glibc uses the hardware, and suffers due to
> > various design/use problems with it. The functions I referred to are
> > used on sane machines like sparc and powerpc.
> >
> > While the paper is interesting, you can't prove correctness by running
> > a few thousand testcases. If you wanted to prove correctness by
> > testing, you have to test *every* input value, all 2^64 of them, or
> > offer some argument that you only need to check a subset.
>
> If you reject a patch IMHO you need to provide a roadmap which leads
> towards acceptance. I.e. tell Roger specifically what he needs to do
> in order to get it accepted. If there is some subset-test or argument
> he could provide you must tell him what it is. Otherwise we'll simply
> discourage him from submitting his contributions. E.g. how was the
> pow routine in glibc proved safe enough?
There was a sequence of papers and some years of research. I believe
<http://tinyurl.com/9il7> is the right reference.
> Some people seem to be so afraid of touching the floating point stuff
> that we risk never being able to improve it. If we follow this course
> of action we'll fall behind competitor compilers who have better
> implementations.
However, if we introduce poor floating point into our compiler, we'll
be in an even worse position than now.
--
- Geoffrey Keating <geoffk@geoffk.org>
More information about the Gcc-patches
mailing list