This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/12134] New: long double precision lost
- From: "jakub at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 18 Oct 2010 21:07:58 +0000
- Subject: [Bug gdb/12134] New: long double precision lost
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=12134
Summary: long double precision lost
Product: gdb
Version: unknown
Status: NEW
Severity: normal
Priority: P2
Component: gdb
AssignedTo: unassigned@sourceware.org
ReportedBy: jakub@redhat.com
Target: x86_64-linux
double d = __DBL_DENORM_MIN__;
long double l1 = (long double) __DBL_DENORM_MIN__;
long double l2 = __LDBL_MIN__;
long double l3 = __LDBL_MIN__ * 0x1p200L;
int
main (void)
{
return 0;
}
gcc -g -o tt tt.c
gdb ./tt
b main
r
(gdb) p d
$1 = 4.9406564584124654e-324
(gdb) p l1
$2 = 4.9406564584124654417656879286822137e-324
(gdb) p l2
$3 = 0
(gdb) p l3
$4 = 0
(gdb) x/2gx &l2
0x600830 <l2>: 0x8000000000000000 0x0000000000000001
(gdb) x/2gx &l3
0x600840 <l3>: 0x8000000000000000 0x00000000000000c9
>From the above it seems that the long double value read from the vars is
somewhere in gdb internally cast to double, then probably cast back to long
double and printed (or goes through text representation or whatever), because
l2 and l3 definitely are not zero.
Also, it would be nice if p/x {d,l1,l2,l3} printed the double/long double vars
using ISO C99 hexadecimal notation (%a/%La for printf) and if hex float
literals could be used in gdb expressions.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.