On Wed, Jan 07, 2015 at 04:08:13PM +0100, Cornelia Huck wrote: > On Sat, 20 Dec 2014 22:03:34 +0000 > Peter Maydell <peter.mayd...@linaro.org> wrote: > > > On 18 December 2014 at 16:34, Cornelia Huck <cornelia.h...@de.ibm.com> > > wrote: > > > Next try for s390x updates. The previous build failures should be > > > fixed now. > > > > Still not building on w32, I'm afraid. I think most of this is run-on > > error from using __uint16_t &c rather than uint16_t &c. > > Sigh. Every time I try to set up a mingw build environment, I get lost > in some library dependencies and give up. > > But yes, the __uint* stuff looks like some copy&paste error from the > respective Linux headers. I'll leave it to Frank to fix that up. >
ok, I'm working on a patch to fix this but I hate to go on this way and steel your time by let you compile test the changes. I do not have a windows build system available so I'm wondering if there is some kind of public infrastructure I can use to do a win build? Thx for any pointers and help ... > > > > You also have a bunch of 64 bit constants like the ZPCI_*_ADDR > > which need a trailing "ULL", and also some with a "UL" which > > should probably be "ULL". For instance in > > > > #define ZPCI_STE_FLAG_MASK 0x7ffUL > > #define ZPCI_STE_ADDR_MASK (~ZPCI_STE_FLAG_MASK) > > > > though ZPCI_STE_FLAG_MASK is OK by itself, when you use it > > in ZPCI_STE_ADDR_MASK you will get the logical-negate done > > at 32 bits before zero-extend to 64 bits, rather than a 64 > > bit negate. > > > > (I think that "UL" is almost never correct in QEMU -- you > > either want "at least 32 bits", in which case "U" is > > sufficient, or you need "64 bits", in which case you need > > "ULL".) > > That's probably also an artifact of grabbing the constants from Linux > (where the code is 64 bit only). > > > > > Some of those suffixes are provoking compiler warnings or > > errors below, but some of them will just be silent wrong > > behaviour, so you should probably eyeball the #defines... > > There are also some possibly dodgy places in non-pci code; I'll take a > look at those as well. > >
