This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/12134] New: long double precision lost


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]