[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] or1k: Fix compilation hiccup
From: |
Peter Maydell |
Subject: |
Re: [PATCH] or1k: Fix compilation hiccup |
Date: |
Fri, 29 May 2020 17:40:13 +0100 |
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.
thanks
-- PMM