bug-autoconf
[Top][All Lists]
Advanced

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

Re: AC_HEADER_STDBOOL fails with clang


From: Eric Blake
Subject: Re: AC_HEADER_STDBOOL fails with clang
Date: Mon, 23 Aug 2010 10:14:05 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.2

On 08/22/2010 08:59 PM, Anders Kaseorg wrote:
But now we have clang.  clang does not (and apparently will not [2])
support this extension, so although it has a working<stdbool.h>, the test
incorrectly fails with CC=clang:

Thanks for the report.


@@ -655,8 +655,7 @@ AC_DEFUN([AC_HEADER_STDBOOL],
            this with GCC, where it should work, to detect more
            quickly whether someone messes up the test in the
            future.  */
-        char digs[] = "0123456789";
-        int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] ==&digs[4] ? 1 : -1);
+        int xlcbug = 1 / (&((char *)0 + 5)[-2 + (bool) 1] ==&((char *)0)[4] ? 
1 : -1);
  #     endif

That is a conditional check, inside:

#       if defined __xlc__ || defined __GNUC__

So does clang define __GNUC__? That's a lie, if it does not support the same extensions as gcc.

Is there another preprocessor macro that we can reliably use to detect if clang is performing the compilation, to skip this code in that case (since we know that clang neither has the AIX bug nor the gcc extension)?

By the way, I note also that the test also fails with CC=gcc CFLAGS='-Wall
-Werror', although for a different reason (error: the address of 's' will
always evaluate as 'true').

We already know that using -Werror during configure is asking for problems, and our recommendation has long been that users should test whether -Werror exists and works independently of blindly sticking it in CFLAGS. There's no way we can reasonably make autoconf be 100% friendly with the use of -Werror behavior across all versions of gcc.

At any rate, thanks for catching the error that we meant to use division by 0 (rather than our typical use of negative array size bounds) as the cause of compilation error on a buggy compiler; you are correct that the (1 / (cond ? 1 : -1)) needs to be fixed to (1 / (cond ? 1 : 0)), whether or not we also get confirmation that changing the expression to something that clang likes will still reject the buggy AIX compiler.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org



reply via email to

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