Bug 55773 - Conversion from long to long double is broken
Summary: Conversion from long to long double is broken
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: sparc64 (show other bugs)
Version: 5.1-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: Stefan Farfeleder
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-20 10:41 UTC by kettenis
Modified: 2005-06-13 12:07 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kettenis 2003-08-20 10:41:50 UTC
Conversion of `long' and `unsigned long' to `long double' are broken
on FreeBSD/sparc64.  GCC generates the right code AFAICT, but the
implementation of _Qp_xtoq() and _Qp_uxtoq() in
/src/lib/libc/sparc64/fpu/fpu_qp.c seem to be broken.  Every value
that has bit 32 set will be negative when converted to a `long
double'.

Fix: 

Looking at the code in /usr/src/lib/libc/sparc64/fpu/fpu_qp.c (I'm
looking at revision 1.3), it seems that the _QP_TTOQ() macro only
handles 32-bit signed integers since on line 63 of that file we have:

	fe.fe_f1.fp_sign = a[0] >> 31;

I think that this line should be

	fe.fe_f1.fp_sign = a[0] >> 63;

for `long' (_Qp_xtoq) and that the line should be completely absent
for `unsigned' (_Qp_uitoq) and `unsigned long' (_Qp_uxtoq).  Some
not-too-thorough testing seems to indicate that's right.
How-To-Repeat: 
The following test program exhibits the behaviour:

#include <stdio.h>

unsigned long mant_long = 0x80000000;

int
main (void)
{
  long double mant = mant_long;
  printf ("%lu\n", mant_long);
  printf ("%Lf\n", mant);
  return 0;
}

which should print

2147483648
2147483648.000000

but will print

2147483648
-2147483648.000000
Comment 1 Jake Burkholder freebsd_committer freebsd_triage 2003-08-20 14:21:36 UTC
Responsible Changed
From-To: freebsd-sparc64->jake

I'll look into this.
Comment 2 Charlie Livingston 2004-11-29 20:44:07 UTC
By the looks of it, this bug also affects /usr/ports/net/isc-dhcp3-server

After spending 3 days pulling my hair out trying to get DDNS working with
bind/dhcpd - I noticed the following in /var/db/dhcpd/dhcpd.leases
--
lease 192.168.55.32 {
  starts 5 -371915209/03/05 13:33:03;
  ends 5 -371915209/03/05 13:43:03;
  tstp 5 -371915209/03/05 13:43:03;
  binding state free;
  hardware ethernet 00:0a:e6:d0:4e:de;
  uid "\001\000\012\346\320N\336";
}
--
It seems to me that this bug is causing DHCPD to mangle dates used by the
daemon.  



-- 
___//____\\___//____\\___\\___//____\\___//____\\___//____\\___//____\\
Charlie Livingston           "What we need to do is take the warning
charlie@sysninjas.com          labels off of everything and let the
http://sysninjas.com            problem of stupidity solve itself"
                                   - Unknown Author
Comment 3 Stefan Farfeleder freebsd_committer freebsd_triage 2005-05-31 08:47:50 UTC
Responsible Changed
From-To: jake->stefanf

Over to me.
Comment 4 Stefan Farfeleder freebsd_committer freebsd_triage 2005-05-31 08:48:08 UTC
State Changed
From-To: open->patched

A fix has been committed to current, thanks for the report.
Comment 5 Stefan Farfeleder freebsd_committer freebsd_triage 2005-06-13 12:07:46 UTC
State Changed
From-To: patched->closed

Fix merged to stable.