Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()

[Richard Henderson <rth@twiddle.net>]

On 11/13/2013 03:04 AM, Anthony Liguori wrote:
> On Tue, Nov 12, 2013 at 8:08 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 12 November 2013 15:58, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> I don't really see a reason why QEMU should give clang more weight than
>>> Windows or Mac OS X.
>>
>> I'm not asking for more weight (and actually my main
>> reason for caring about clang is exactly MacOSX). I'm
>> just asking that when a bug is reported whose underlying
>> cause is "we don't work on clang because we're relying on
>> undocumented behaviour of gcc" with an attached patch that
>> fixes this by not relying on the undocumented behaviour,
>> that we apply the patch rather than saying "why do we
>> care about clang"...
> 
> QEMU has always been intimately tied to GCC.  Heck, it all started as
> a giant GCC hack relying on entirely undocumented behavior (dyngen's
> disassembly of functions).
> 
> There's nothing intrinsically bad about being tied to GCC.  If you
> were making argument that we could do it a different way and the
> result would be as nice or nicer, then it wouldn't be a discussion.
> 
> But if supporting clang means we have to remove useful things, then
> it's always going to be an uphill battle.
> 
> In this case, the whole discussion is a bit silly.  Have you actually

For what it's worth, I think BOTH of the patches that have been posted
should be applied.  That is, the patch that does (X || 1) -> (1 || X),
and the patch that adds the stub.

Frankly I'd have thought this was obvious and I'm a bit dismayed about
how long this thread has continued.

As far as GCC is concerned, we consider trivial dead code elimination
like this to be a quality of implementation issue.  We would never
remove it, even from -O0.  We can't guarantee how successful we can
be, but that's what bug reports and regression tests are for.


r~