[llvm-commits] [llvm] r49458 - /llvm/trunk/lib/Transforms/IPO/SimplifyLibCalls.cpp

Neil Booth neil at daikokuya.co.uk
Fri Apr 11 07:33:10 PDT 2008


Chris Lattner wrote:-

> His response:
> 
> I stand behind the claim that the behavior of the pow(x, 0.5) -> sqrt  
> substitution is incompatible with C99.  Here are the exact citations:
> 
>  From C99, Annex F (normative):
> 
> 	F.9.4.4 The pow functions
> 
> 	? pow(+-0, y) returns +0 for y > 0 and not an odd integer.
> 	? pow(-inf, y) returns +inf for y > 0 and not an odd integer.
> 
> 	F.9.4.5 The sqrt functions
> 
> 	sqrt is fully specified as a basic arithmetic operation in IEC 60559
> 
>  From IEC 60559 (IEEE 754-1985), section 5.2:
> 
> 	... the square root of -0 shall be -0.
> 
> Does that pin things down enough for you?

I have no opinion on this, but I'll note that NetBSD's man page
says something subtlely different:

 The function pow(x, y) checks to see if x < 0 and y is not an integer, in
 the event this is true, the global variable errno is set to EDOM and on
 the VAX generate a reserved operand fault.

I assume we're talking about pow (-0.0, 0.5) here.  I'm not sure whether
-0.0 qualifies as negative.  Clearly it's sign is negative, but it is
not less than zero (both being quite reasonable definitions of
"negative").  NetBSD's man page removes the ambiguity; on NetBSD this
transformation is unambiguously valid, because -0.0 < 0 is false.

The choice of the ambiguous adjective "negative" when applied to
a value is unfortunate here.  It's probably best to ask on comp.std.c
what was intended.  Personally I would be surprised if the intent
was to differ from IEEE 754 as that is what the C standard has been
doing its best recently to converge on, as far as is possible.

Whereas F.9.4.4 seems clear that pow (-0, 0.5) is +0.0,  F.9.1
confusingly states "this subclause contains specifications of <math.h>
facilities that are particularly suited for IEC 60559 implementations."
See also F.9.3, which basically claims math.h is intended to be
consistent with IEC 60559.  Hoho.

The fact that -0 is apparently 0.0 after promotion doesn't help either.
Hehe.

Neil.



More information about the llvm-commits mailing list