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

[Eric Blake]

-----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             address@hidden
-----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-----