[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