[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#515153: marked as done (libc6-dev: ieee754.h has wrong union for long double on amd64)

Your message dated Sun, 26 Apr 2009 19:28:14 +0200
with message-id <20090426172814.GG4902@hall.aurel32.net>
and subject line Re: Bug#515153: libc6-dev: ieee754.h has wrong union for long double on amd64
has caused the Debian Bug report #515153,
regarding libc6-dev: ieee754.h has wrong union for long double on amd64
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
515153: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515153
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6-dev
Version: 2.7-18
Severity: normal

/usr/include/ieee754.h includes unions to break down the different
floating-point types into their component bits.  Unfortunately, this
file contains a 96-bit version for long double, whilst amd64 uses a
128-bit long double.  Thus, the problem does not exist when using -m32,
but does for 64-bit programs.

A sample program is attached; it successfully runs with -m32, but fails
without it.

This problem does not occur on sparc.

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6-dev depends on:
ii  l 2.7-18                                 GNU C Library: Shared libraries
ii  l 2.6.28-1~experimental.1~snapshot.12762 Linux support headers for userspac

Versions of packages libc6-dev recommends:
ii  gcc [c-compiler]              4:4.3.2-3  The GNU C compiler
ii  gcc-3.4 [c-compiler]          3.4.6-9    The GNU C compiler
ii  gcc-4.1 [c-compiler]          4.1.2-25   The GNU C compiler
ii  gcc-4.2 [c-compiler]          4.2.4-6    The GNU C compiler
ii  gcc-4.3 [c-compiler]          4.3.3-3    The GNU C compiler

Versions of packages libc6-dev suggests:
pn  glibc-doc                     <none>     (no description available)
ii  manpages-dev                  3.17-1     Manual pages about using GNU/Linux

-- no debconf information

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

#include <stddef.h>
#include <stdio.h>
#include <ieee754.h>

int main(void)
{
	union ieee854_long_double ild;
	const size_t ld = sizeof(long double);
	const size_t ilds = sizeof(ild.ieee);
	printf("%d %d %s\n", ld, ilds, (ld == ilds ? "ok" : "fail"));
	return ld != ilds;
}

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message --- 
On Fri, Feb 13, 2009 at 11:38:47PM +0000, brian m. carlson wrote:
> Package: libc6-dev
> Version: 2.7-18
> Severity: normal
>
> /usr/include/ieee754.h includes unions to break down the different
> floating-point types into their component bits.  Unfortunately, this
> file contains a 96-bit version for long double, whilst amd64 uses a
> 128-bit long double.  Thus, the problem does not exist when using -m32,
> but does for 64-bit programs.
>

amd64 uses 96-bit long double just like i386. sizeof(long double) is
128-bit on this architecture only for alignement reasons.

The union correctly breaks down a long double into the different parts,
closing the bug.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: