qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 00/38] First set of s390x patches for 2.8


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PULL 00/38] First set of s390x patches for 2.8
Date: Tue, 6 Sep 2016 17:04:18 +0200

On Tue, 6 Sep 2016 16:49:08 +0200
Cornelia Huck <address@hidden> wrote:

> On Tue, 6 Sep 2016 15:32:26 +0100
> Peter Maydell <address@hidden> wrote:
> 
> > On 6 September 2016 at 08:46, Cornelia Huck <address@hidden> wrote:
> > > The following changes since commit 
> > > e87d397e5ef66276ccc49b829527d605ca07d0ad:
> > >
> > >   Open 2.8 development tree (2016-09-05 11:38:54 +0100)
> > >
> > > are available in the git repository at:
> > >
> > >   git://github.com/cohuck/qemu tags/s390x-20160906
> > >
> > > for you to fetch changes up to f216f2122519e24f57e09103ea5beb4c43f241c0:
> > >
> > >   s390x/cpumodel: implement QMP interface "query-cpu-model-baseline" 
> > > (2016-09-05 15:49:23 +0200)
> > >
> > > ----------------------------------------------------------------
> > > First (big) chunk of s390x updates:
> > > - cpumodel support for s390x
> > > - various fixes and improvements
> > >
> > > ----------------------------------------------------------------
> > 
> > Hi; I'm afraid this causes compile warnings with clang, which look
> > like they're flagging up a genuine bug:
> > 
> >   CC    ppc-softmmu/migration/savevm.o
> > /Users/pm215/src/qemu-for-merges/target-s390x/cpu_models.c:254:11:
> > warning: explicitly assigning value of variable of type 'FILE *' (aka
> > 'struct __sFILE *') to itself [-Wself-assign]
> >         f = f,
> >         ~ ^ ~
> > /Users/pm215/src/qemu-for-merges/target-s390x/cpu_models.c:255:15:
> > warning: explicitly assigning value of variable of type
> > 'fprintf_function' (aka 'int (*)(FILE *, const char *, ...)') to
> > itself [-Wself-assign]
> >         print = print,
> >         ~~~~~ ^ ~~~~~
> > 2 warnings generated.
> > 
> > Looks like you forgot the '.' on the front of the field
> > names in the structure initializer.
> 
> Ugh, yes.
> 
> Looks trivial enough to fix up: I'll probably just do that and send a
> v2.

...although gcc seems to be clever enough to just Do The Right Thing
anyway, so we never noticed this...




reply via email to

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