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

Bug#464594: glibc: ieee754.h uses BIG_ENDIAN instead of __BIG_ENDIAN causing doubles to be mixed up on arm



Package: libc6
Version: 2.7-6
Severity: normal
File: glibc


On arm, compiling the following code with gcc-4.2 
gives different results depending on whether the
flag -ansi is passed:

#include <float.h>
#include <ieee754.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

int main(void) {
 union ieee754_double val;
 uint64_t bits;
 
 val.d = DBL_MAX;
 
 bits = ((uint64_t) val.ieee.negative) << 63
   | ((uint64_t) val.ieee.exponent) << 52
   | ((uint64_t) val.ieee.mantissa0) << 32
   | ((uint64_t) val.ieee.mantissa1);

 printf("%llx\n", bits);

 exit(EXIT_SUCCESS);
}

the good:

$ gcc-4.2 test-double.c
$ ./a.out
0x7fefffffffffffff

the bad:

$ gcc-4.2 -ansi test-double.c
$ ./a.out
0xffffffff7fefffff

i.e. the words are flipped around.

In a conversation on #debian-arm, pbrooks noted that
the tests in file ieee754.h whether to flip the 
mantissa bits (which is necessary on arm) depends
on BIG_ENDIAN, instead of __BIG_ENDIAN.

Defining BIG_ENDIAN as __BIG_ENDIAN makes the code
print out the expected result.

This seems to be an upstream issue, too. A fix could 
be to patch sysdeps/ieee754/ieee754.h to use __BIG_ENDIAN
everywhere.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm (armv5tejl)

Kernel: Linux 2.6.18-4-versatile
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1                 1:4.3-20080127-1 GCC support library

libc6 recommends no packages.

-- debconf information excluded



Reply to: