From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8shw-0007WP-CI for qemu-devel@nongnu.org; Wed, 07 Jan 2015 10:39:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y8shr-00039q-A2 for qemu-devel@nongnu.org; Wed, 07 Jan 2015 10:39:40 -0500 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:33284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8shr-00039K-1O for qemu-devel@nongnu.org; Wed, 07 Jan 2015 10:39:35 -0500 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Jan 2015 15:39:32 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id A52981B08051 for ; Wed, 7 Jan 2015 15:40:02 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t07FdTT758327044 for ; Wed, 7 Jan 2015 15:39:29 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t07FdRrn014492 for ; Wed, 7 Jan 2015 08:39:28 -0700 Date: Wed, 7 Jan 2015 16:39:26 +0100 From: Frank Blaschka Message-ID: <20150107153926.GA15898@tuxmaker.boeblingen.de.ibm.com> References: <1418920467-24506-1-git-send-email-cornelia.huck@de.ibm.com> <20150107160813.601a7a20.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150107160813.601a7a20.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [PULL v2 0/7] s390x patches for 2.3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Peter Maydell , Frank Blaschka , QEMU Developers , Alexander Graf , Christian Borntraeger , Jens Freimann On Wed, Jan 07, 2015 at 04:08:13PM +0100, Cornelia Huck wrote: > On Sat, 20 Dec 2014 22:03:34 +0000 > Peter Maydell wrote: > > > On 18 December 2014 at 16:34, Cornelia Huck 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. > >