aboutsummaryrefslogtreecommitdiff
path: root/gdb/sparc-nat.c
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@gnat.com>2012-10-24 18:11:21 +0000
committerJoel Brobecker <brobecker@gnat.com>2012-10-24 18:11:21 +0000
commit3256027470cc5339e32600cd0d5900f3ce3344e7 (patch)
tree57de7e6b7467258ef88e879bd8f14d2799f4dab8 /gdb/sparc-nat.c
parent5a04cc987f921c041f358e0b2a7390ba7dcd1aa1 (diff)
downloadgdb-3256027470cc5339e32600cd0d5900f3ce3344e7.zip
gdb-3256027470cc5339e32600cd0d5900f3ce3344e7.tar.gz
gdb-3256027470cc5339e32600cd0d5900f3ce3344e7.tar.bz2
off-by-one max exponent computation in convert_doublest_to_floatformat
Assuming the following variable definition: long double inp = 2.0; On platforms where "long double" is a double precision IEEE flaoting point, GDB currently behaves as follow: (gdb) set variable inp = 1.6e+308l (gdb) p inp $2 = inf <<<<---- !!!! Instead, the value of "inp" should be printed as: (gdb) p inp $1 = 1.6e+308 The problem is due to a small error in the comparison of the exponent versus the maximum value this exponent can take, causing us to think that the value was too big to fit. But it isn't. gdb/ChangeLog: * doublest.c (convert_doublest_to_floatformat): Fix comparison against maximum exponent value. gdb/testsuite/ChangeLog: * gdb.base/ldbl_e308.c, gdb.base/ldbl_e308.exp: New files.
Diffstat (limited to 'gdb/sparc-nat.c')
0 files changed, 0 insertions, 0 deletions