From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDwTi-0000Nx-Td for qemu-devel@nongnu.org; Wed, 21 Jan 2015 09:41:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDwTd-0000zg-R5 for qemu-devel@nongnu.org; Wed, 21 Jan 2015 09:41:54 -0500 Received: from mail-la0-f46.google.com ([209.85.215.46]:47722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDwTd-0000zV-KA for qemu-devel@nongnu.org; Wed, 21 Jan 2015 09:41:49 -0500 Received: by mail-la0-f46.google.com with SMTP id s18so19640210lam.5 for ; Wed, 21 Jan 2015 06:41:48 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <87mw5cfdyy.fsf@blackfin.pond.sub.org> References: <1420790680-3266-1-git-send-email-blaschka@linux.vnet.ibm.com> <1420790680-3266-3-git-send-email-blaschka@linux.vnet.ibm.com> <87h9vln5tm.fsf@blackfin.pond.sub.org> <20150120110348.66afc423.cornelia.huck@de.ibm.com> <87ppa9iqco.fsf@blackfin.pond.sub.org> <87bnlthaqe.fsf@blackfin.pond.sub.org> <20150120142052.GA44419@tuxmaker.boeblingen.de.ibm.com> <87bnltryii.fsf@blackfin.pond.sub.org> <87twzkmjqx.fsf@blackfin.pond.sub.org> <87mw5cfdyy.fsf@blackfin.pond.sub.org> From: Peter Maydell Date: Wed, 21 Jan 2015 14:41:28 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 2/3 V3] s390: implement pci instructions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Cornelia Huck , Christian Borntraeger , Frank Blaschka , Frank Blaschka , QEMU Developers On 21 January 2015 at 13:41, Markus Armbruster wrote: > I suspect we shift signed values all over the place, without regard for > signed overflow. Machines are fine with that, but some day some > compiler wiseguy may find a way to save a femtosecond or two for some > program that never does that, breaking programs that do it, and then > we'll be in trouble. clang with its undefined behaviour sanitizers will warn at runtime when we do this. I've sent out some patches to fix instances of this in the past. Coverity will also warn in some cases I think. > We should follow the kernel's lead and compile with > -fno-strict-overflow. I don't believe that option affects signed shifts, only signed addition, subtraction and multiplication. -- PMM