> -----Original Message----- > From: David Gibson [mailto:da...@gibson.dropbear.id.au] > Sent: Thursday, October 29, 2020 7:39 AM > To: Thomas Huth <th...@redhat.com> > Cc: Chenqun (kuhn) <kuhn.chen...@huawei.com>; qemu-triv...@nongnu.org; > Euler Robot <euler.ro...@huawei.com>; qemu-devel@nongnu.org; ganqixin > <ganqi...@huawei.com>; Zhanghailiang <zhang.zhanghaili...@huawei.com>; > qemu-...@nongnu.org > Subject: Re: [PATCH 7/9] ppc: silence the compiler warnings > > On Wed, Oct 28, 2020 at 03:42:31PM +0100, Thomas Huth wrote: > > On 28/10/2020 05.29, David Gibson wrote: > > > On Wed, Oct 28, 2020 at 12:18:17PM +0800, Chen Qun wrote: > > >> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed > warning: > > >> hw/ppc/ppc.c: In function ‘ppc6xx_set_irq’: > > >> hw/ppc/ppc.c:118:16: warning: this statement may fall through > [-Wimplicit-fallthrough=] > > >> 118 | if (level) { > > >> | ^ > > >> hw/ppc/ppc.c:123:9: note: here > > >> 123 | case PPC6xx_INPUT_INT: > > >> | ^~~~ > > >> > > >> Add the corresponding "fall through" comment to fix it. > > >> > > >> Reported-by: Euler Robot <euler.ro...@huawei.com> > > >> Signed-off-by: Chen Qun <kuhn.chen...@huawei.com> > > > > > > Acked-by: David Gibson <da...@gibson.dropbear.id.au> > > > > > >> --- > > >> Cc: David Gibson <da...@gibson.dropbear.id.au> > > >> --- > > >> hw/ppc/ppc.c | 1 + > > >> 1 file changed, 1 insertion(+) > > >> > > >> diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c index > > >> 4a11fb1640..f9eb8f21b4 100644 > > >> --- a/hw/ppc/ppc.c > > >> +++ b/hw/ppc/ppc.c > > >> @@ -120,6 +120,7 @@ static void ppc6xx_set_irq(void *opaque, int pin, > int level) > > >> } else { > > >> cpu_ppc_tb_stop(env); > > >> } > > >> + /* fall through */ > > >> case PPC6xx_INPUT_INT: > > >> /* Level sensitive - active high */ > > >> LOG_IRQ("%s: set the external IRQ state to %d\n", > > > > > > > Is that fall through actually really the right thing to do here? I'd > > rather expect to see a PPC_INTERRUPT_DECR instead of a > > PPC_INTERRUPT_EXT in case someone messes with the TBEN pin? So I > > assume this is likely rather bug and we should a "break" statement here > instead? > > Oh.. good catch, I think I misread this. I thought the change was correct, > because DECRs look somewhat like external interrupts. But this is TBEN, not > a DECR interrupt per se. So, yes, I think this was a bug and it should be a > break instead. > This bug looks like it's been hidden for years. Thanks for your point. According to your opinion, I will modify it in the next version.
Thanks, Chen Qun > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ > _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson
