From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61836 invoked by alias); 25 Feb 2015 23:07:44 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 61790 invoked by uid 48); 25 Feb 2015 23:07:40 -0000 From: "jsm28 at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug math/18031] New: [ldbl-128ibm] modfl problems Date: Wed, 25 Feb 2015 23:07:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: math X-Bugzilla-Version: 2.21 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jsm28 at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg00377.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=18031 Bug ID: 18031 Summary: [ldbl-128ibm] modfl problems Product: glibc Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: math Assignee: unassigned at sourceware dot org Reporter: jsm28 at gcc dot gnu.org The ldbl-128ibm implementation of modfl has several issues: * In the case for high part exponent < 52, (((i0&i)|(i1&0x7fffffffffffffffLL))==0) is not a correct test for integer argument; the latter part effectively tests just if the low part is a power of 2. Example: an argument of 0x1.ffffffffffffffp51L is wrongly treated as being an integer. * In that case, the handling of non-integers when detected as such fails to allow for the low part being of opposite sign to the integer high part. Example: 0x1.ffffffffffffff1p51L produces integer part 0x1p+52, fractional part -0x1.ep-6. * The case of high part exponent > 103 is treated as meaning the argument is an integer, but that's not true even when restricted to numbers with 106 contiguous mantissa bits. Example: 0x1.ffffffffffffffffffffffffff8p104L is wrongly treated as being an integer. * In the case for exponents 52 to 103, the test i1&i)==0 for being an integer is completely bogus; the mask i = -1ULL>>(j0-52) is computed as if this were a conventional IEEE format. Example: 0x0.fffffffffffffcp52L is wrongly treated as being an integer. * When something is detected as not an integer in that case, the INSERT_WORDS64 (xlo, i1&(~i)) is always inserting a subnormal / zero value in the low part, its exponent having been masked off earlier. Example: 0x1.00000000000001111p56L gets integer part 0x1p+56 and fractional part 0x1.111p+0, which is more than 1. -- You are receiving this mail because: You are on the CC list for the bug.