This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: gcc -ffast-math defect with tan(x)
On 2009-11-17 14:32Z, Dave Korn wrote:
[...]
> WTF? The fptan has returned two QNaNs for no apparent reason?
"When stack overflow occurs during FPTAN and overflow is masked,
both ST(0) and ST(1) contain quiet NaNs." [intel 80387 manual]
>> R7: Special 0xffffc000000000000000 Real Indefinite (QNaN)
>> =>R6: Special 0xffffc000000000000000 Real Indefinite (QNaN)
>> R5: Empty 0xd8021027c0001027bff8
>> R4: Empty 0xd8d0611dae800022bf20
>> R3: Empty 0x0c656120a86000000000
>> R2: Empty 0x001e0000007700000042
>> R1: Empty 0xc52c0022c530001a75de
>> R0: Empty 0x170800ce00cc507c0000
>>
>> Status Word: 0xffff3241 IE SF C1
[...]
> Hmm. I think the C1 indicates it believes there has been a stack underflow,
"When both IE and SF bits of status word are set, indicating a stack exception,
this bit distinguishes between stack overflow (C1=1) and underflow (C1=0)." [ibid.]
> and maybe that happens because the r6 slot is valid rather than empty the
> second time round; maybe _f_tan needs to be 'popping' (or in some way marking
> invalid) that unused +1.0 constant rather than just skipping the stack pointer
> over it. I'll see if that makes a difference; I'm not an x87 specialist, I
> only know just enough to get by. I see that the fincstp documentation does
> warn that "this operation is not equivalent to popping the stack", so I may be
> on the right track.
Maybe this sheds some light:
"For FPTAN, FSIN, FCOS, and FSINCOS, the reduction bit is set if the operand at
the top of the stack is too large. In this case the original operand remains at
the top of the stack." [ibid.]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple