>>>>> "Uros" == Uros Bizjak <[EMAIL PROTECTED]> writes:
Uros> Hello!
>> Fair enough, so with 64 bit floats you have no right to expect an
>> accurate answer for sin(2^90). However, you DO have a right to
>> expect an answer in the range [-1,+1] rather than the 1.2e+27 that
>> Richard quoted. I see no words in the description of
>> -funsafe-math-optimizations to lead me to expect such a result.
>>
Uros> The source operand to fsin, fcos and fsincos x87 insns must be
Uros> within the range of +-2^63, otherwise a C2 flag is set in FP
Uros> status word that marks insufficient operand reduction. Limited
Uros> operand range is the reason, why fsin & friends are enabled
Uros> only with -funsafe-math-optimizations.
Uros> However, the argument to fsin can be reduced to an acceptable
Uros> range by using fmod builtin. Internally, this builtin is
Uros> implemented as a very tight loop that check for insufficient
Uros> reduction, and could reduce whatever finite value one wishes.
Uros> Out of curiosity, where could sin(2^90) be needed? It looks
Uros> rather big angle to me.
It looks that way to me too, but it's a perfectly valid argument to
the function as has been explained by several people.
Unless -funsafe-math-optimizations is *explicitly* documented to say
"trig function arguments must be in the range x..y for meaningful
results" I believe it is a bug to translate sin(x) to a call to the
x87 fsin primitive. It needs to be wrapped with fmod (perhaps after a
range check for efficiency), otherwise you've drastically changed the
semantics of the function.
Personally I don't expect sin(2^90) to yield 1.2e27. Yes, you can
argue that, pedantically, clause (b) in the doc for
-funsafe-math-optimizations permits this. Then again, I could argue
that it also permits sin(x) to return 0 for all x.
paul
