[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
Re: [Qemu-devel] [PATCH] Drop QEMU_GNUC_PREREQ() checks for gcc older than 4.1
Tue, 31 Jan 2017 19:58:01 +0100
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
Peter Maydell <address@hidden> writes:
> On 31 January 2017 at 17:40, Markus Armbruster <address@hidden> wrote:
>> 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
>>> 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))
>>> -#define QEMU_WARN_UNUSED_RESULT
>> 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.)