X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
X-Spam-Check-By:	sourceware.org
X-Yahoo-SMTP:	mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw
Message-ID:	<4B02D18E.5000805@sbcglobal.net>
Date:	Tue, 17 Nov 2009 16:38:38 +0000
From:	Greg Chicares <gchicares AT sbcglobal DOT net>
User-Agent:	Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: gcc -ffast-math defect with tan(x)
References:	<AE5F3949C74C6547AEAEAB87D1AC7F1B057788A6 AT cos-us-mb01 DOT cos DOT agilent DOT com> <4B028ED0 DOT 5070600 AT gmail DOT com> <loom DOT 20091117T143159-735 AT post DOT gmane DOT org> <4B02B41A DOT 5010806 AT gmail DOT com>
In-Reply-To:	<4B02B41A.5010806@gmail.com>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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

- Raw text -