[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Drop QEMU_GNUC_PREREQ() checks for gcc older th
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH] Drop QEMU_GNUC_PREREQ() checks for gcc older than 4.1 |
Date: |
Tue, 31 Jan 2017 18:40:13 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Peter Maydell <address@hidden> 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 <address@hidden>
> ---
> 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?
>
> -#if QEMU_GNUC_PREREQ(4, 0)
> #define QEMU_SENTINEL __attribute__((sentinel))
> -#else
> -#define QEMU_SENTINEL
> -#endif
Likewise.
>
> #if QEMU_GNUC_PREREQ(4, 3)
> #define QEMU_ARTIFICIAL __attribute__((always_inline, artificial))
[Nothing to say on the rest...]
Regardless of my question:
Reviewed-by: Markus Armbruster <address@hidden>