diff options
| author | Joel Brobecker <brobecker@gnat.com> | 2012-10-24 18:11:20 +0000 |
|---|---|---|
| committer | Joel Brobecker <brobecker@gnat.com> | 2012-10-24 18:11:20 +0000 |
| commit | 7332ce74bfbc4470f7245004b9a8ea6276aa1710 (patch) | |
| tree | 1e04e3d8a1599dfcccb9964a234df4f33e2f1fee /gdb/doublest.c | |
| parent | 31337e61a3a460b806281db79bdf05ad4660e43e (diff) | |
| download | gdb-7332ce74bfbc4470f7245004b9a8ea6276aa1710.tar.gz | |
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/doublest.c')
| -rw-r--r-- | gdb/doublest.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/doublest.c b/gdb/doublest.c index f683002020f..0308dac6190 100644 --- a/gdb/doublest.c +++ b/gdb/doublest.c @@ -483,7 +483,7 @@ convert_doublest_to_floatformat (CONST struct floatformat *fmt, goto finalize_byteorder; } - if (exponent + fmt->exp_bias >= (1 << fmt->exp_len) - 1) + if (exponent + fmt->exp_bias >= (1 << fmt->exp_len)) { /* The value is too large to fit into the destination. Treat as infinity. */ |