From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14854 invoked by alias); 10 Jun 2003 19:16:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14821 invoked from network); 10 Jun 2003 19:16:32 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 10 Jun 2003 19:16:32 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 88B0D800021 for ; Tue, 10 Jun 2003 15:16:32 -0400 (EDT) Message-ID: <3EE62E90.1000806@redhat.com> Date: Tue, 10 Jun 2003 19:16:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: RFA: patch to convert_doublest_to_floatformat in doublest.c Content-Type: multipart/mixed; boundary="------------000708040804000402080800" X-SW-Source: 2003-06/txt/msg00335.txt.bz2 This is a multi-part message in MIME format. --------------000708040804000402080800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1322 The attached patch fixes a bug in convert_doublest_to_floatformat when converting to a IEEE single float format that has an implied integer bit. The problem is that the code is performing a shift to discard the top bit. It then subtracts one from the number of mantissa bits. Later on, the code does a shift of 32 - mantissa_bits to the right, then puts "mant_bits" into the result. For a single float, we have 23 bits of mantissa. If we shift the value, we still have 23 bits to put into the result. According to the algorithm, we will only put 22 bits and will shift 10 bits to the right, thereby losing the last bit. This in fact, causes the error for Bugzilla bug 85109 whereby p print_two_floats(*f3) in call-rt-st.exp does not print one of the values correctly. It is in fact printing what is given to it which has the last bit zeroed out. The old algorithm is correct for floating values whereby there are 32 or more mantissa bits. In such a case, we only can put 31 bits into the result. A simple test was added. The patch has been tested on the ia64 and x86. Ok to commit? -- Jeff J. 2003-06-10 Jeff Johnston * doublest.c (convert_doublest_to_floatformat): When dealing with the implied integer bit, only alter mant_bits if we are processing a full 32 bits of mantissa. --------------000708040804000402080800 Content-Type: text/plain; name="doublest.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="doublest.patch" Content-length: 1003 Index: doublest.c =================================================================== RCS file: /cvs/src/src/gdb/doublest.c,v retrieving revision 1.15 diff -u -p -r1.15 doublest.c --- doublest.c 8 Jun 2003 18:27:13 -0000 1.15 +++ doublest.c 10 Jun 2003 18:44:30 -0000 @@ -404,7 +404,15 @@ convert_doublest_to_floatformat (CONST s { mant_long <<= 1; mant_long &= 0xffffffffL; - mant_bits -= 1; + /* If we are processing the top 32 mantissa bits of a doublest + so as to convert to a float value with implied integer bit, + we will only be putting 31 of those 32 bits into the + final value due to the discarding of the top bit. In the + case of a small float value where the number of mantissa + bits is less than 32, discarding the top bit does not alter + the number of bits we will be adding to the result. */ + if (mant_bits == 32) + mant_bits -= 1; } if (mant_bits < 32) --------------000708040804000402080800--