Below is a reduced case when building binutils/gdb with clang. This code compiles well if -D_FORTIFY_SOURCE=2 and -O2 are not set. It pops out the following error if -D_FORTIFY_SOURCE=2 and -O2 are set. gcc does not have this problem. cat f.c <<<<<<<< #define _GNU_SOURCE #define ATTRIBUTE_NONNULL(m) __attribute__ ((__nonnull__ (m))) #define ATTRIBUTE_PRINTF(m, n) __attribute__ ((__format__ (__printf__, m, n))) ATTRIBUTE_NONNULL(m) #define ATTRIBUTE_PRINTF_2 ATTRIBUTE_PRINTF(2, 3) #include <stdio.h> extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2; >>>>>>>>>>>>>>> /usr/bin/clang -D_FORTIFY_SOURCE=2 -c -O2 ./f.c -o a -B/usr/libexec/gcc/x86_64-cros-linux-gnu -target x86_64-cros-linux-gnu ./f.c:30:12: error: expected parameter declarator extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2; ^ /usr/include/bits/stdio2.h:199:24: note: expanded from macro 'asprintf' __asprintf_chk (ptr, __USE_FORTIFY_LEVEL - 1, __VA_ARGS__) ^ /usr/include/features.h:346:31: note: expanded from macro '__USE_FORTIFY_LEVEL' # define __USE_FORTIFY_LEVEL 2 ^ ./f.c:30:12: error: expected ')' /usr/include/bits/stdio2.h:199:24: note: expanded from macro 'asprintf' __asprintf_chk (ptr, __USE_FORTIFY_LEVEL - 1, __VA_ARGS__) ^ /usr/include/features.h:346:31: note: expanded from macro '__USE_FORTIFY_LEVEL' # define __USE_FORTIFY_LEVEL 2 ^ ./f.c:30:12: note: to match this '(' /usr/include/bits/stdio2.h:199:18: note: expanded from macro 'asprintf' __asprintf_chk (ptr, __USE_FORTIFY_LEVEL - 1, __VA_ARGS__) ^ ./f.c:30:50: error: '__nonnull__' attribute parameter 1 is out of bounds extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2; ^~~~~~~~~~~~~~~~~~ ./f.c:26:28: note: expanded from macro 'ATTRIBUTE_PRINTF_2' #define ATTRIBUTE_PRINTF_2 ATTRIBUTE_PRINTF(2, 3) ^ ~ ./f.c:25:80: note: expanded from macro 'ATTRIBUTE_PRINTF' #define ATTRIBUTE_PRINTF(m, n) __attribute__ ((__format__ (__printf__, m, n))) ATTRIBUTE_NONNULL(m) ^ ./f.c:23:46: note: expanded from macro 'ATTRIBUTE_NONNULL' #define ATTRIBUTE_NONNULL(m) __attribute__ ((__nonnull__ (m))) ^ ./f.c:30:50: error: '__format__' attribute parameter 2 is out of bounds extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2; ^~~~~~~~~~~~~~~~~~ ./f.c:26:28: note: expanded from macro 'ATTRIBUTE_PRINTF_2' #define ATTRIBUTE_PRINTF_2 ATTRIBUTE_PRINTF(2, 3) ^ ~ ./f.c:25:48: note: expanded from macro 'ATTRIBUTE_PRINTF' #define ATTRIBUTE_PRINTF(m, n) __attribute__ ((__format__ (__printf__, m, n))) ATTRIBUTE_NONNULL(m) ^ ./f.c:30:12: error: conflicting types for '__asprintf_chk' extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2; ^ /usr/include/bits/stdio2.h:199:3: note: expanded from macro 'asprintf' __asprintf_chk (ptr, __USE_FORTIFY_LEVEL - 1, __VA_ARGS__) ^ /usr/include/bits/stdio2.h:158:12: note: previous declaration is here extern int __asprintf_chk (char **__restrict __ptr, int __flag, ^ 5 errors generated.
glibc defines asprintf to this: # define asprintf(ptr, ...) \ __asprintf_chk (ptr, __USE_FORTIFY_LEVEL - 1, __VA_ARGS__) When we apply that to your decl, we get this code: extern int __asprintf_chk (char **, 2 - 1, const char *, ...); So, basically glibc makes it impossible to redeclare asprintf with this particular combination of ifdefs, which might be a bug. GCC -E shows that it doesn't do that: $ gcc t.c -D_FORTIFY_SOURCE=2 -O2 -E -o - | tail -1 extern int asprintf (char **, const char *, ...) __attribute__ ((__format__ (__printf__, 2, 3))) __attribute__ ((__nonnull__ (2))); Looking at stdio2.h shows that GCC defines __va_arg_pack, so it gets this inline function instead of the macro definition: # ifdef __va_arg_pack __fortify_function int __NTH (asprintf (char **__restrict __ptr, const char *__restrict __fmt, ...)) { return __asprintf_chk (__ptr, __USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); } So, if you want to make clang accept this code without changing glibc's _FORTIFY_SOURCE implementation, you will need to implement this builtin and convince people that it's worth having. Given that it's impossible to codegen __va_arg_pack without inlining, I'm not sure how that'll go.
It turns out it is a bug inside libiberty.