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

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