| Summary: | long double precision lost | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Jakub Jelinek <jakub> |
| Component: | gdb | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ssbssa |
| Priority: | P2 | ||
| Version: | unknown | ||
| Target Milestone: | 8.1 | ||
| Host: | Target: | x86_64-linux | |
| Build: | Last reconfirmed: | ||
This works since gdb-8.1: ``` (gdb) p d $1 = 4.9406564584124654e-324 (gdb) p l1 $2 = 4.94065645841246544177e-324 (gdb) p l2 $3 = 3.36210314311209350626e-4932 (gdb) p l3 $4 = 5.40269144938955163113e-4872 ``` |
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.