From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1640 invoked by alias); 17 Jun 2013 22:42:55 -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 1596 invoked by uid 48); 17 Jun 2013 22:42:52 -0000 From: "jsm28 at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug soft-fp/7006] Bad left shift in _FP_FRAC_SRS_2 macro in soft-fp/op-2.h on SH-4 Date: Mon, 17 Jun 2013 22:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: soft-fp X-Bugzilla-Version: 2.8 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: Message-ID: In-Reply-To: References: 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: 2013-06/txt/msg00139.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=7006 --- Comment #3 from Joseph Myers --- Indeed, I don't actually see how the _SRS macros can be called with a shift count of 0. In the interest of efficiency, I'm inclined to say we should define the interfaces to all the shift macros to require a shift count that is strictly positive and strictly less than the total number of bits in the given number of words, then review all shift counts for cases that might violate this; I expect checking for 0 at any rare call sites where it might occur will be more efficient than making these macros handle the case of 0. In one such review attempt, I can see the use of *left* shift for converting integers to floating point may shift by 0. The following testcase illustrates that on x86_64 for conversion from unsigned __int128 to __float128 (soft-fp as used in libgcc): #include #ifdef COMPILE_TIME # define VOL /* Empty. */ #else # define VOL volatile #endif int main (void) { VOL unsigned long long a = 0x1000000000000ULL; VOL unsigned long long b = 0xffffffffffffffffULL; unsigned __int128 c = (((unsigned __int128) a) << 64) | b; __float128 d = c; if (d != 0x1.000000000000ffffffffffffffffp112q) abort (); exit (0); } If you define COMPILE_TIME and build with optimization, the test passes as the conversion is done at compile time; otherwise, it is done at runtime and a right-shift by 64 in _FP_FRAC_SLL_2 called to shift left by 0 results in an incorrect result. -- You are receiving this mail because: You are on the CC list for the bug.