From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23579 invoked by alias); 22 Mar 2012 13:42:48 -0000 Received: (qmail 23555 invoked by uid 22791); 22 Mar 2012 13:42:47 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Mar 2012 13:42:30 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 6E5022F78015 for ; Thu, 22 Mar 2012 13:42:29 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvlx0AR275aZ; Thu, 22 Mar 2012 13:42:23 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001539] Single precision floating point math library X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: sergei.gavrikov@gmail.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 22 Mar 2012 13:42:00 -0000 Message-Id: <20120322134223.9ECDB2F78005@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2012-03/txt/msg00109.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539 --- Comment #19 from Sergei Gavrikov 2012-03-22 13:42:17 GMT --- (In reply to comment #18) > (In reply to comment #12) > > (In comment #9 I wrote) > > > > > All f-tests fail on eCos synthetic target > > > > My fault (that was wrong grep GDB output)! I'm sorry. Only below fails: > > > > FAIL: Line: 92, File: tests/vectors/sqrtf.c > > FAIL: Line: 92, File: tests/vectors/log10f.c > > FAIL: Line: 92, File: tests/vectors/frexpf.c > > FAIL: Line: 92, File: tests/vectors/acosf.c > > FAIL: Line: 92, File: tests/vectors/asinf.c > > FAIL: Line: 92, File: tests/vectors/logf.c > > > > So, I got the same results for eCos sythetic target as for ARM7 target. > > > > Sergei > > Tests expect NaN for out-of-domain arguments, but functions return something > else. For instance asinf(10) returns 0. Here is a little example: IMO, it can depend on libm compatibility, look at libm compat. wrappers (w_*.c), e.g. at w_asin{,f}.c. Though, I think in our case it should be a result of call __ieee754_asin{,f}(). And if libm compat mode is not IEEE? I'm looking at misc/standard.c (__kernel_standard)... > int main(void) > { > volatile float fla, flb, flc; > volatile double dla, dlb, dlc; > > printf("Enter floats: "); > scanf("%f %f", &fla, &flb); > printf("Enter doubles: "); > scanf ("%lf %lf", &dla, &dlb); > > flc = fla + flb; > dlc = dla + dlb; > printf("float: %f + %f = %f\n", fla, flb, flc); > printf("double: %f + %f = %f\n", dla, dlb, dlc); > > flc = fla / flb; > dlc = dla / dlb; > printf("float: %f / %f = %f\n", fla, flb, flc); > printf("double: %f / %f = %f\n", dla, dlb, dlc); > > flc = asinf(fla); > dlc = asin(dla); > printf("float: asinf(%f) = %f\n", fla, flc); > printf("double: asin(%f) = %f\n", dla, dlc); > > return 0; > } > > And some printouts: > > Enter floats: 0 0 > Enter doubles: 0 0 > float: 0.000000 + 0.000000 = 0.000000 > double: 0.000000 + 0.000000 = 0.000000 > float: 0.000000 / 0.000000 = nan > double: 0.000000 / 0.000000 = nan > float: asinf(0.000000) = 0.000000 > double: asin(0.000000) = 0.000000 > > Enter floats: 10 10 > Enter doubles: 10 10 > float: 10.000000 + 10.000000 = 20.000000 > double: 10.000000 + 10.000000 = 20.000000 > float: 10.000000 / 10.000000 = 1.000000 > double: 10.000000 / 10.000000 = 1.000000 > float: asinf(10.000000) = 0.000000 > double: asin(10.000000) = 0.000000 > > As we can the same behavior is for double. I haven't check but I could > imagine that double's tests either don't contain these cases or expect > 0. Thank you for the example. > I wander if this is some compatibility issue?! FYI Linux man pages say > they should return NaN. Further I would refer to http://sourceware.org/newlib/libm.html and thus to http://sourceware.org/newlib/libm.html#asin However, they also talk about NaN, errno (EDOM), etc. > Then next question: what to fix, functions or tests? Do you trust your checkErrorAcceptableFloat() implementation? As I could see asin*(10.0) should return N-a-N if libm compat is IEEE. IMHO, we have to compare return values for d-implementations with f-ones and then test (compare) behaviors of its checkers. I will try to investigate tonight. Sergei -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.