From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTsPc-0004Gq-HY for qemu-devel@nongnu.org; Tue, 07 Jun 2011 05:17:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTsPa-0004ZF-GF for qemu-devel@nongnu.org; Tue, 07 Jun 2011 05:17:24 -0400 Received: from mail-px0-f174.google.com ([209.85.212.174]:33837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTsPa-0004Z3-0Q for qemu-devel@nongnu.org; Tue, 07 Jun 2011 05:17:22 -0400 Received: by pxi15 with SMTP id 15so1575200pxi.33 for ; Tue, 07 Jun 2011 02:17:20 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4DEDEC9B.8010203@redhat.com> Date: Tue, 07 Jun 2011 11:17:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1307370348-28400-1-git-send-email-pbonzini@redhat.com> <1307370348-28400-2-git-send-email-pbonzini@redhat.com> <4DED518E.6090001@twiddle.net> In-Reply-To: <4DED518E.6090001@twiddle.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/3] move WORDS_ALIGNED to qemu-common.h List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org On 06/07/2011 12:15 AM, Richard Henderson wrote: > Do we take his existing 3-part patch as-is, and the packed patch as a followup? > Do we convert to packed accesses first and move it around after? > Do we do it all in one step? Either of the first two works for me. However, since this series was a start towards fixing real bugs reported by Coverity: qemu-kvm-0.14.0/hw/scsi-bus.c:190: sign_extension: Suspicious implicit sign extension: "cmd[10]" with type "unsigned char" (8 bits, unsigned) is promoted in "cmd[13] | (cmd[12] << 8) | (cmd[11] << 16) | (cmd[10] << 24)" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "cmd[13] | (cmd[12] << 8) | (cmd[11] << 16) | (cmd[10] << 24)" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. ... and there were objections on requiring recent GCC, perhaps it's better to just commit it as is. Paolo