Re: [PATCH] or1k: Fix compilation hiccup

[Markus Armbruster]

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

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

You didn't *have* to, but it'll help if you do :)