qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 00/35] cmpxchg atomic operations


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL 00/35] cmpxchg atomic operations
Date: Mon, 24 Oct 2016 15:02:44 +0100

On 24 October 2016 at 13:37, Paolo Bonzini <address@hidden> wrote:
> On 24/10/2016 12:51, Peter Maydell wrote:
>> This fails to build with clang (OSX and linux):
>>
>> /Users/pm215/src/qemu-for-merges/target-arm/translate.c:1019:1: error:
>> unused function 'gen_aa32_ld16ua
>> ' [-Werror,-Wunused-function]
>> DO_GEN_LD(16ua, MO_UW | MO_ALIGN)
>> ^
>> /Users/pm215/src/qemu-for-merges/target-arm/translate.c:954:20: note:
>> expanded from macro 'DO_GEN_LD'
>> static inline void gen_aa32_ld##SUFF(DisasContext *s, TCGv_i32 val,      \
>>                    ^
>> <scratch space>:130:1: note: expanded from here
>> gen_aa32_ld16ua
>> ^
>> /Users/pm215/src/qemu-for-merges/target-arm/translate.c:1020:1: error:
>> unused function 'gen_aa32_ld32ua
>> ' [-Werror,-Wunused-function]
>> DO_GEN_LD(32ua, MO_UL | MO_ALIGN)
>> ^
>> /Users/pm215/src/qemu-for-merges/target-arm/translate.c:954:20: note:
>> expanded from macro 'DO_GEN_LD'
>> static inline void gen_aa32_ld##SUFF(DisasContext *s, TCGv_i32 val,      \
>>                    ^
>> <scratch space>:131:1: note: expanded from here
>> gen_aa32_ld32ua
>> ^
>>
>> The other builds passed OK.
>
> LLVM bug https://llvm.org/bugs/show_bug.cgi?id=22712:
>
>   we should probably consider the functions to not be in the main
>   source file if they were expanded from a macro that was defined
>   outside that file. That perhaps doesn't go far enough (consider a
>   macro defined in the main source file, that produces several
>   functions, where after each macro invocation only a subset of the
>   functions is used)

That just says "even if we fixed this bug it wouldn't affect
the situation we have here"...

In any case, since DO_GEN_LD(16ua, ...) only and exactly produces
one function (gen_aa32_ld16ua), the fix would seem to be just to not
have that macro invocation if we never use the function it produces.
(We don't even conditionally use the function as far as I can tell.)

thanks
-- PMM



reply via email to

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