Does this is a loss of precision when using decimal floating types in GDB?

[Junling Zheng]

Ping.

Does anybody have some ideas?

Cheer,

Junling

On 2015/4/28 15:44, Junling Zheng wrote:
> 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 at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 
>