qemu-trivial
[Top][All Lists]
Advanced

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

Re: [PATCH] or1k: Fix compilation hiccup


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH] or1k: Fix compilation hiccup
Date: Mon, 8 Jun 2020 08:22:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 6/8/20 8:03 AM, Markus Armbruster wrote:
> Markus Armbruster <armbru@redhat.com> writes:
> 
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> On Fri, 29 May 2020 at 17:23, Christophe de Dinechin
>>> <dinechin@redhat.com> wrote:
>>>> On 2020-05-26 at 20:51 CEST, Eric Blake wrote...
>>>>> diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c
>>>>> index d08ce6181199..95011a8015b4 100644
>>>>> --- a/hw/openrisc/openrisc_sim.c
>>>>> +++ b/hw/openrisc/openrisc_sim.c
>>>>> @@ -129,7 +129,7 @@ static void openrisc_sim_init(MachineState *machine)
>>>>>      const char *kernel_filename = machine->kernel_filename;
>>>>>      OpenRISCCPU *cpu = NULL;
>>>>>      MemoryRegion *ram;
>>>>> -    qemu_irq *cpu_irqs[2];
>>>>> +    qemu_irq *cpu_irqs[2] = {};
>>>>
>>>> Why is the value [2] correct here? The loop that initializes loops over
>>>> machine->smp.cpus. Is it always less than 2 on this machine?
>>>
>>> Yes: openrisc_sim_machine_init() sets mc->max_cpus = 2.
>>> My suggestion of adding an assert() is essentially telling the
>>> compiler that indeed smp_cpus must always be in the range [1,2],
>>> which we can tell but it can't.
>>
>> Do we have a proper patch for this on the list?
> 
> Apparently not.
> 
> Philippe did try Peter's suggestion, found it works, but then posted it
> only to Launchpad.  Philippe, please post to the list, so we can finally
> get this fixed.

Sorry since it was Eric finding, I didn't understood I had to post it.
Will do.




reply via email to

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