Re: Bug report: sort.c or AIX compiler

[Paul Eggert]

"Lemley James - jlemle" <address@hidden> writes:

> Oh, I get it.  I didn't realize you wanted fail at compile time.  Hm...
>
> No, that fails to compile in both 64-bit and 32-bit mode, as well as my
> old development Linux box (gcc 2.96 on Redhat 7.2)

It's OK to fail with gcc 2.96, since that doesn't support a conforming
stdbool.  However, I'm starting to think that there may be no way to
check for this at compile-time.

For now, I have reinstalled the substitution of 'int' for 'bool' in
sort.c, since I'm no longer confident in the stdbool.m4 fix.  However,
I'd like to get to the bottom of the stdbool.m4 problem.

Can you please try this patch to stdbool.m4 instead?  That is,
please take coreutils 5.90, apply this patch without changing sort.c,
and then run 'make'.  It should rerun aclocal/autoconf/etc. and then
should determine that stdbool.h does not work on your xlc host.  It
should then substitute coreutils's stdbool.h, which should then work.
Please let me know if that happens.  Thanks.

Also, could you please report the xlc bug to IBM?

I have installed this change into coreutils, since I don't think it
hurts, and it may fix the problem.

2005-10-07  Paul Eggert  <address@hidden>

        * m4/stdbool.m4 (AC_HEADER_STDBOOL): Add an "#ifdef __xlc__" test,
        since yesterday's attempt didn't work.

2005-10-06  Paul Eggert  <address@hidden>

        * stdbool.m4 (AC_HEADER_STDBOOL): Check that bool
        promotes to int, not unsigned int, to catch the AIX 5.3
        compiler bug.

--- coreutils-5.90/m4/stdbool.m4        2005-01-21 22:25:53.000000000 -0800
+++ coreutils-cvs1/m4/stdbool.m4        2005-10-07 11:50:30.000000000 -0700
@@ -1,6 +1,6 @@
 # Check for stdbool.h that conforms to C99.
 
-dnl Copyright (C) 2002-2004 Free Software Foundation, Inc.
+dnl Copyright (C) 2002-2005 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
@@ -70,10 +70,27 @@ AC_DEFUN([AC_HEADER_STDBOOL],
          enum { j = false, k = true, l = false * true, m = true * 256 };
          _Bool n[m];
          char o[sizeof n == m * sizeof n[0] ? 1 : -1];
+         char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
+         #if defined __xlc__ || __GNUC__
+          /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
+             reported by James Lemley on 2005-10-05; see
+             
<http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html>.
+             This test is not quite right, since xlc is allowed to
+             reject this program, as the initializer for xlcbug is
+             not one of the forms that C requires support for.
+             However, doing the test right would require a run-time
+             test, and that would make crosss-compilation harder.
+             Let us hope that IBM fixes the xlc bug, and also adds
+             support for this kind of constant expression.  In the
+             meantime, this test will reject xlc, which is OK, since
+             our stdbool.h substitute should suffice.  */
+          char digs[] = "0123456789";
+          int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);
+         #endif
        ],
        [
          return (!a + !b + !c + !d + !e + !f + !g + !h + !i + !j + !k + !l
-                 + !m + !n + !o);
+                 + !m + !n + !o + !p);
        ],
        [ac_cv_header_stdbool_h=yes],
        [ac_cv_header_stdbool_h=no])])