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 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: <4B028ED0 DOT 5070600 AT gmail DOT com> <4B02B41A DOT 5010806 AT gmail DOT com> In-Reply-To: <4B02B41A.5010806@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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