qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] Drop QEMU_GNUC_PREREQ() checks f


From: Peter Maydell
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] Drop QEMU_GNUC_PREREQ() checks for gcc older than 4.1
Date: Tue, 31 Jan 2017 18:00:13 +0000

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
>> 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?

We have attributes which we wrap in QEMU_ macros already
even though they always expand to the same thing:
QEMU_NORETURN and QEMU_ALIGNED. 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.)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]