[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