-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[adding bug-gnulib]
According to Nelson H. F. Beebe on 10/14/2008 2:23 PM:
> 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;
Thanks for the report. This is a gnulib testsuite problem; and since it
didn't strike until the gnulib portion of the testsuite, I suspect that
your m4 executable built just fine. What needs to happen now is relaxing
the gnulib unit test to find a way to generate -0.0L in a way that doesn't
upset your broken compiler (all that is failing to compile is the unit
test that checks that either your native frexpl or the gnulib replacement
correctly handles -0.0L).
> 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.
M4's use of long double is limited to strtold and printf("%Lf") (and for
that matter, limited to the format builtin, which is a GNU extension).
Since both of these functions have gnulib replacements for systems with
broken libc/libm, it is merely a matter of making sure gnulib provides the
desired portability and workarounds for your platform.
>
> 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
Gnulib also provides a replacement <float.h> that works around these bugs.
> #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.
Not necessary. M4's use of long double is so limited that gnulib provides
enough to effectively use the type.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj1RsIACgkQ84KuGfSFAYB8CgCeNZZLN4uIT5LigRhPyeU5OS9e
lv0An0SNS/TKuZtOhzg12LrRKBDCvIaj
=FFqK
-----END PGP SIGNATURE-----
