Clang and glibc 2.25 incompatibilities?

I'm running into a weird situation with Clang 3.9.1 and glibc 2.25
(on Arch Linux). With this file:

    #include <assert.h>

    int main(void)
    {
        assert(1);
        return 0;
    }

I run Clang as such:

    clang -pedantic test.c

and I get this warning:

    test.c:4:5: warning: use of GNU statement expression extension
                [-Wgnu-statement-expression]
        assert(1);
        ^
    /usr/include/assert.h:95:6: note: expanded from macro 'assert'
        ({ \
         ^
    1 warning generated.

I don't have this warning with glibc 2.24. The difference is that in
glibc 2.24, assert.h contains:

    # define assert(expr) \
      ((expr) \
       ? __ASSERT_VOID_CAST (0) \
       : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION))

whereas in glibc 2.25, assert.h contains:

    # if !defined __GNUC__ || defined __STRICT_ANSI__
    # define assert(expr) \
        ((expr) \
         ? __ASSERT_VOID_CAST (0) \
         : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION))
    # else
    # define assert(expr) \
        ({ \
          if (expr) \
            ; /* empty */ \
          else \
            __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION); \
        })
    # endif

And it looks like Clang defines __GNUC__, so it reaches the statement
expression. A workaround is:

    clang -pedantic -U__GNUC__ test.c

Why does Clang define __GNUC__ by default?

What's the real solution here?

Thank you for your time,
Phil

Why does Clang define __GNUC__ by default?

Because it creates less problems than the alternatives. There is a lot
of code in the wild that essentially assumes a random version of gcc for
a lot of code. Given that Clang is implementing almost all the GCC
extensions of GCC 4.2.1, it claims to be that version. It means a bit
more work for newer code, but avoids breaking a lot of older code.

What's the real solution here?

Create a bug report against glibc.

Joerg

Why does Clang define __GNUC__ by default?

Because it creates less problems than the alternatives. There is a lot
of code in the wild that essentially assumes a random version of gcc for
a lot of code. Given that Clang is implementing almost all the GCC
extensions of GCC 4.2.1, it claims to be that version. It means a bit
more work for newer code, but avoids breaking a lot of older code.

What's the real solution here?

Create a bug report against glibc.

Is it really a glibc issue? The header uses a GNU statement expression
when __GNUC__ is defined. Clang defines __GNUC__, but with -pedantic
it complains that I'm using a GNU extension. In other words Clang pretends
to be GCC by default, but complains when exposed to GCC extensions.

I don't think glibc is doing anything wrong here.

Phil

The compiler identification macro has nothing to do with the language
mode. __STRICT_ANSI__ is not the right check, that's what applies only
for -std=cXX.

Joerg

It is. This is also an incorrect definition for C++11, where assert(true) is required to be a constant expression.