qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stu


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()
Date: Tue, 12 Nov 2013 15:13:47 +0000

On 12 November 2013 14:57, Paolo Bonzini <address@hidden> wrote:
> Il 12/11/2013 15:09, Gleb Natapov ha scritto:
>> On Tue, Nov 12, 2013 at 02:57:49PM +0100, Paolo Bonzini wrote:
>>> Il 12/11/2013 14:23, Gleb Natapov ha scritto:
>>>>> If -O0 does not do that, let's move debug builds to -O1.
>>>>
>>>> Why not enable dce with -fdce?
>>>
>>> First, because clang doesn't have fine-tuned optimization options (at
>>> least I couldn't find them and -fdce doesn't work).
>>
>> -O1 then for clang.
>
> We can even test in configure for the exact optimizations we want, in
> fact.  But I think -O1 doesn't sacrifice debuggability that much:

I'm afraid I still don't see why you'd want to sacrifice it
at all, when the alternative is "provide a three line stub
function in a file we already have all the build machinery
to compile in the config where it's needed". I just don't
see why you'd worry about the fact that there's no longer
a compile error if you try to call this obviously kvm
specific function in a non-kvm-enabled code path, when
we already have large numbers of kvm-specific functions
that have stubs (and when in general, eg QOM APIs, we seem
to be entirely happy to have things be runtime errors rather
than compile time). To me the benefit seems entirely on the
side of "have standard compliant code" rather than "attempt
to find various odd workarounds for the fact that some
compilers will correctly complain about our code".

-- PMM



reply via email to

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