bug-gnulib
[Top][All Lists]
Advanced

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

Re: 'long double' support on MacOS X and BSD platforms


From: Bruno Haible
Subject: Re: 'long double' support on MacOS X and BSD platforms
Date: Sat, 18 Oct 2008 13:11:06 +0200
User-agent: KMail/1.5.4

Hello Nelson,

> > Builds of m4-1.4.12 fail on Apple Mac OS X 10.x PowerPC systems
> > with this error:
> >
> >     gcc -std=gnu99  -I. -I../lib  -I. -I. -I.. -I./.. -I../lib -I./../lib 
> > -I/usr/local/include  -g -O2
> >     -MT test-frexpl.o -MD -MP -MF .deps/test-frexpl.Tpo -c -o test-frexpl.o 
> > test-frexpl.c
> >     test-frexpl.c:62: error: initializer element is not constant
> 
> > The problem statement in m4 is
> >
> >     long double minus_zero = -LDBL_MIN * LDBL_MIN;

A workaround to this compiler bug has been added to gnulib now.

> > on Mac OS X PowerPC
> > systems, long double is only partially supported by the compiler and
> > run-time library, and I have found it unusable in numeric code.

Do you have more details about this, so that we could write an autoconf
test against it, or tell us which library functions are affected?

> > For that reason, one of my own header files has code like this:
> >
> >     #if defined(HAVE_OS_FREEBSD) || defined(HAVE_OS_NETBSD) || 
> > defined(HAVE_OS_OPENBSD)
> >     /* On these systems, <float.h> lies about the characteristics of long 
> > double:
> >        the constants reflect 80-bit IEEE 754 data, but the compilers 
> > generate code
> >        as if for 64-bit data.  There is thus no way to check for this brain 
> > damage
> >        at compile time, other than by testing for this private symbol, 
> > sigh... */
> >     #define HAVE_BROKEN_LONG_DOUBLE 1

In my experience, the situation on FreeBSD/x86, NetBSD/x86, OpenBSD/x86 is
all different.

For a platform to support the CPU's 80-bit "extended double" data type as
'long double', three pieces are necessary:
  - compiler support, e.g. when folding constant expressions,
  - initialization of the FPU control flags at runtime, before main(),
  - <float.h>'s LDBL_* values.

On OpenBSD, only <float.h> is wrong, and this is fixed by gnulib.

On NetBSD, the FPU control flags initialization is missing, and gnulib contains
a module 'fpucw' to work around it.

On FreeBSD, the three pieces are consistent: 'long double' is equivalent to
a 'double', only stored with 80 bits. The FreeBSD developers force users
who want access to the computational power of their CPU to switch over to
Linux. gnulib cannot provide a workaround against this.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]