[Top][All Lists]
[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/ -
-------------------------------------------------------------------------------
- m4-1.4.12: problem on Apple Mac OS X 10.x PowerPC,
Nelson H. F. Beebe <=