Peter Maydell <peter.mayd...@linaro.org> writes: > On 31 January 2017 at 17:40, Markus Armbruster <arm...@redhat.com> wrote: >> Peter Maydell <peter.mayd...@linaro.org> writes: >> >>> We already require gcc 4.1 or newer (for the atomic >>> support), so the fallback codepaths for older gcc >>> versions than that are now dead code and we can >>> just delete them. >>> >>> NB: clang reports itself as gcc 4.2 (regardless of >>> clang version), so clang won't be using the fallbacks >>> either. >>> >>> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> >>> --- >>> For compatibility with clang we should probably try to avoid >>> using QEMU_GNUC_PREREQ() and instead have something in >>> compiler.h that abstracts away whether the test for "does >>> the compiler support feature foo" is via a GCC version >>> check or a clang __has_feature or whatever. >> >> Yes, testing for feature is better than testing a version. >> >> This patch reduces use of QEMU_GNUC_PREREQ roughly by half. Good. >> >>> >>> >>> include/qemu/compiler.h | 8 --- >>> include/qemu/host-utils.h | 121 >>> ---------------------------------------------- >>> tcg/arm/tcg-target.h | 7 --- >>> 3 files changed, 136 deletions(-) >>> >>> diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h >>> index 157698b..fc12e49 100644 >>> --- a/include/qemu/compiler.h >>> +++ b/include/qemu/compiler.h >>> @@ -24,17 +24,9 @@ >>> >>> #define QEMU_NORETURN __attribute__ ((__noreturn__)) >>> >>> -#if QEMU_GNUC_PREREQ(3, 4) >>> #define QEMU_WARN_UNUSED_RESULT __attribute__((warn_unused_result)) >>> -#else >>> -#define QEMU_WARN_UNUSED_RESULT >>> -#endif >> >> Should we inline this macro? > > We have attributes which we wrap in QEMU_ macros already > even though they always expand to the same thing: > QEMU_NORETURN and QEMU_ALIGNED.
We also use attributes that are supported by all compilers of interest without wrapping them in macros. Just grep for __attribute__. > I'm happy to leave these > to follow that pattern. (If you wanted to send a patch > series that uninlined all of those then I wouldn't hugely > object to it, but I think it touches enough files that it's > a separate thing from removing the #if guards that this > patch does.) Makes sense.
