[prev in list] [next in list] [prev in thread] [next in thread]
List: uclibc
Subject: Does this is a loss of precision when using decimal floating types in GDB?
From: Junling Zheng <zhengjunling () huawei ! com>
Date: 2015-04-28 7:44:39
Message-ID: 553F3A67.5050703 () huawei ! com
[Download RAW message or body]
Hi, all
When testing gdb in uClibc, a testcase(<gdb-7.6>/gdb/testsuite/gdb.base/dfp-exprs.exp) failed at:
166 gdb_test "p (_Decimal64) 3.1" " = 3.(0999.*|1000.*)"
And we got some unexpected results:
1) For most numbers, the trailing "0" will be left out:
(gdb) p (_Decimal64) 3.1
$1 = 3.1
(gdb) p (_Decimal64) 3.2
$2 = 3.2
(gdb) p (_Decimal64) 3.5
$3 = 3.5
(gdb) p (_Decimal64) 3.9
$4 = 3.9
(gdb) p (_Decimal64) 3.90001
$5 = 3.90001
2) However, for a little few numbers, the trailing "0" will NOT be left out:
(gdb) p (_Decimal64) 1.1
$6 = 1.100000000000000
(gdb) p (_Decimal64) 4.9
$7 = 4.900000000000000
And in glibc, the result is:
(gdb) p (_Decimal64) 3.1
$1 = 3.100000000000000
(gdb) p (_Decimal64) 3.2
$2 = 3.200000000000000
(gdb) p (_Decimal64) 3.5
$3 = 3.5 // followed IEEE Standard for Floating-Point Arithmetic (IEEE 754)
(gdb) p (_Decimal64) 3.9
$4 = 3.900000000000000
(gdb) p (_Decimal64) 3.90001
$5 = 3.900010000000000
(gdb) p (_Decimal64) 1.1
$6 = 1.100000000000000
(gdb) p (_Decimal64) 4.9
$7 = 4.899999999999999
According to the description in http://git.uclibc.org/uClibc/tree/docs/Glibc_vs_uClibc_Differences.txt:
...
stdio
-----
1) Conversion of large magnitude floating-point values by printf suffers a loss
of precision due to the algorithm used.
...
But I doubt that this is a loss of precision or a bug in uClibc or gdb?
Does anyone encounter this problem?
Cheers,
Junling
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic