This is the mail archive of the gdb-prs@sources.redhat.com 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]

gdb/363: print/d (long double)1



>Number:         363
>Category:       gdb
>Synopsis:       print/d (long double)1
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 20 07:38:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     ac131313@redhat.com
>Release:        unknown-1.0
>Organization:
>Environment:
i386 GDB target
>Description:
On the i386 architecture, sizeof(long double) > sizeof (LONGEST) which leads to wierd behavour when printing floating point values.

(gdb) print/d (long double)1
$1 = 302222231531620438900736
(gdb) print/d (double)1
$2 = 1
(gdb) print/d (float)1
$3 = 1
(gdb) 

My take on the logic in printcmd.c is that if sizeof(HOST LONGEST) < sizeof(TARGET TYPE) it figures that the conversion will be lossy so instead prints the value raw.

Unfortunatly, even ``print/d (float)val'' is potentially lossy:

(gdb) print/d (float)1e20
$5 = -9223372036854775808

I think floating point values should always be converted to integer.

Separatly, GDB could do with host independant integer and floating point support so that it can handle edge cases consistently.
>How-To-Repeat:
(gdb) print/d (long double)1
$1 = 302222231531620438900736
(gdb) print/d (double)1
$2 = 1
(gdb) print/d (float)1
$3 = 1
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


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