Message ID | 20140225115043.GC12803@kentang.lan |
---|---|
State | New |
Headers | show |
On 25 February 2014 11:50, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote: > Hi Peter, > > This branch contains updates for SPARC, particularly a new implementation of the CG3 framebuffer as > reviewed on list, plus timer/hostid fixes from Olivier. Please pull. Hi. This fails to build on 32 bit, I'm afraid: /root/qemu/hw/display/cg3.c: In function 'cg3_reg_write': /root/qemu/hw/display/cg3.c:202:5: error: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'uint64_t' [-Werror=format] > http://github.com/mcayland/qemu.git qemu-sparc PS: if you could be consistent with the URL you use in pull requests that would be nice; I have you recorded as https://... (not a big deal, but it means my cut-n-paste "apply this" doesn't work and I have to tweak it by hand.) thanks -- PMM
On 26/02/14 18:45, Peter Maydell wrote: > On 25 February 2014 11:50, Mark Cave-Ayland > <mark.cave-ayland@ilande.co.uk> wrote: >> Hi Peter, >> >> This branch contains updates for SPARC, particularly a new implementation of the CG3 framebuffer as >> reviewed on list, plus timer/hostid fixes from Olivier. Please pull. > > Hi. This fails to build on 32 bit, I'm afraid: > > /root/qemu/hw/display/cg3.c: In function 'cg3_reg_write': > /root/qemu/hw/display/cg3.c:202:5: error: format '%lx' expects > argument of type 'long unsigned int', but argument 2 has type > 'uint64_t' [-Werror=format] Ah I see. Looks like I accidentally used a direct format identifier rather than one of the standard format macros which is what caused the breakage on a different architecture. I've just updated my qemu-sparc branch with an updated version which uses HWADDR_PRIx for displaying addresses and PRIx64 for displaying the 64-bit value field for those 2 lines in question which should resolve it. >> http://github.com/mcayland/qemu.git qemu-sparc > > PS: if you could be consistent with the URL you use in pull > requests that would be nice; I have you recorded as https://... > (not a big deal, but it means my cut-n-paste "apply this" > doesn't work and I have to tweak it by hand.) Yes, my fault entirely. I sent pull request remotely in order to submit it before freeze and obviously made a typo. I'll resubmit a PULLv2 shortly which will have the correct URL. Many thanks, Mark.