[cfe-dev] Clang and glibc 2.25 incompatibilities?

Philippe Proulx via cfe-dev cfe-dev at lists.llvm.org
Sat Apr 1 07:31:54 PDT 2017


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



More information about the cfe-dev mailing list