On Dec 4, 2006, at 11:27 AM, Richard Guenther wrote:
On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard,
Somewhere, in a mail lost in my large e-mail clash with my ISP
(verizon), you said that gfortran couldn't profit from the pow(x,
1./3.)
-> cbrt(x) conversion because gfortran didn't "know" of cbrt.
Could you be more explicit about this - I'd like to repair this
deficiency, if at all possible.
Thanks in advance !
It's a matter of making the cbrt builtin available - I have a patch
for this,
but wondered if the fortran frontend can rely on the cbrt library
call being
available? Or available in a fast variant, not a fallback
implementation in
libgfortran which does pow (x, 1./3.) which will then of course
pessimize
pow (x, 2./3.) -> tmp = cbrt(x); tmp * tmp expansion.
Is pow(x, 1./3.) == cbrt(x) ?
My handheld calculator says (imagining a 3 decimal digit machine):
pow(64.0, .333) == 3.99
In other words, can pow assume that if it sees .333, that the client
actually meant the non-representable 1/3? Or must pow assume that .
333 means .333? My inclination is that if pow(x, 1./3.) (computed
correctly to the last bit) ever differs from cbrt(x) (computed
correctly to the last bit) then this substitution should not be done.
-Howard
