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

[Bernhard Reutner-Fischer]

On May 5, 2015 3:45:43 AM GMT+02:00, Junling Zheng <zhengjunling at huawei.com> wrote:
>Ping.
>
>Does anybody have some ideas?

IIRC a couple of years ago I have seen this too. Again IIRC it went away when compiling most if not all concerned parts with -O0

Do you have a small, standalone C-testcase ?

Thanks,
>
>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
>> 
>>