bug-m4
[Top][All Lists]
Advanced

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

m4-1.4.12: problem on Apple Mac OS X 10.x PowerPC


From: Nelson H. F. Beebe
Subject: m4-1.4.12: problem on Apple Mac OS X 10.x PowerPC
Date: Tue, 14 Oct 2008 14:23:41 -0600 (MDT)

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 is a serious 1989 and 1999 ISO C C Standards violation on
the part of Apple, and I've had to work around it several times in my
own numeric code.  

The problem statement in m4 is

        long double minus_zero = -LDBL_MIN * LDBL_MIN;

Its preprocessor expansion is

        long double minus_zero = -2.00416836000897277799610805135016e-292L *
                                  2.00416836000897277799610805135016e-292L;

The Standard requires that LDBL_MIN, and other constants defined in
<float.h>, be compile-time constants, and thus, this assignment is
correct.  

However, Apple's brain-damaged port of gcc refuses to compile constant
expressions of type long double when it thinks that they might not be
exactly representable.  Here is an example that exhibits what Apple's
compiler does:

        % cat foo.c
        static long double one = 1.0L * 1.0L;
        static long double quarter = 0.5L * 0.5L;
        static long double third = 1.0L / 3.0L;

        % cc -c foo.c
        foo.c:3: error: initializer element is not constant

The problem is even worse, however, because 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.

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
        #elif defined(__APPLE_CC__) && defined(FP_ARCH_POWERPC)
        /* Although <float.h> has 64-bit data for the long double constants, 
other
           irregularities make long double unusable on Apple Macintosh PowerPC
           systems, even after 15 years of production!.  No such problem exists
           for the newer Apple Macintosh Intel systems. */
        #define HAVE_BROKEN_LONG_DOUBLE 1
        #endif

When HAVE_BROKEN_LONG_DOUBLE is defined, the remainder of my code
falls back from long double to double.

I suggest that m4 be redesigned to have a similar fallback to double
on systems with broken long double, or where long double is treated
like double.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------




reply via email to

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