From: "J. Johnston" <jjohnstn@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: RFA: patch to convert_doublest_to_floatformat in doublest.c
Date: Tue, 10 Jun 2003 19:16:00 -0000 [thread overview]
Message-ID: <3EE62E90.1000806@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
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 <jjohnstn@redhat.com>
* 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.
[-- Attachment #2: doublest.patch --]
[-- Type: text/plain, Size: 1003 bytes --]
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)
next reply other threads:[~2003-06-10 19:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-10 19:16 J. Johnston [this message]
2003-06-11 21:20 ` Kevin Buettner
2003-06-11 21:25 ` J. Johnston
2003-06-11 22:15 ` Kevin Buettner
2003-06-11 23:35 ` J. Johnston
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EE62E90.1000806@redhat.com \
--to=jjohnstn@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox