qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PULL 00/24] ppc-for-2.12 queue 20180302


From: David Gibson
Subject: Re: [Qemu-ppc] [PULL 00/24] ppc-for-2.12 queue 20180302
Date: Mon, 5 Mar 2018 10:55:57 +1100
User-agent: Mutt/1.9.2 (2017-12-15)

On Fri, Mar 02, 2018 at 02:26:49PM +0000, Peter Maydell wrote:
> On 2 March 2018 at 06:03, David Gibson <address@hidden> wrote:
> > The following changes since commit 0dc8ae5e8e693737dfe65ba02d0c6eccb58a9c67:
> >
> >   Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20180301-v2' into 
> > staging (2018-03-01 17:08:16 +0000)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180302
> >
> > for you to fetch changes up to 57ae75b2e401f1d04f37a8cd26212eb3134c51a6:
> >
> >   hw/ppc/spapr,e500: Use new property "stdout-path" for boot console 
> > (2018-03-02 12:24:44 +1100)
> >
> > ----------------------------------------------------------------
> > ppc patch queue 2018-03-02
> >
> > Here's the next batch of accumulated spapr and ppc patches.
> > Highlights are:
> >     * New Sam460ex machine type
> >     * Yet more fixes related to vcpu id allocation for spapr
> >     * Numerous macio cleanupsr
> >     * Some enhancements to the Spectre/Meltdown fixes for pseries,
> >       allowing use of a better mitigation for indirect branch based
> >       exploits
> >     * New pseries machine types with Spectre/Meltdown mitigations
> >       enabled (stop gap until libvirt and management understands the
> >       machine options)
> >     * A handful of other fixes
> >
> 
> Hi. This generates a compile error from some compilers in my test set
> (I think just the older gccs):
> 
> /home/petmay01/linaro/qemu-for-merges/hw/ppc/ppc440_uc.c: In function
> ‘ppc460ex_pcie_realize’:
> /home/petmay01/linaro/qemu-for-merges/hw/ppc/ppc440_uc.c:1054:5:
> error: ‘id’ may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>      snprintf(buf, sizeof(buf), "pcie%d-io", id);
>      ^
> cc1: all warnings being treated as errors
> 
> Looks like a valid complaint to me -- the realize function
> should check that dcrn_base was set to a valid value, fail
> realize if it wasn't, and have a 'default:' case in the
> switch with g_assert_not_reached().

Bother.  I wonder why my compiler didn't catch that.

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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