Re: [Qemu-trivial] [Qemu-devel] [PATCH] Drop QEMU_GNUC_PREREQ() checks for gcc older than 4.1

[Markus Armbruster]

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

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.