From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZykKA-0007zM-M9 for qemu-devel@nongnu.org; Tue, 17 Nov 2015 12:45:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZykK4-0007TB-Sa for qemu-devel@nongnu.org; Tue, 17 Nov 2015 12:45:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZykK4-0007T3-Me for qemu-devel@nongnu.org; Tue, 17 Nov 2015 12:45:40 -0500 References: <1447769349-1767-1-git-send-email-pbonzini@redhat.com> <874mgkh6f5.fsf@blackfin.pond.sub.org> From: Paolo Bonzini Message-ID: <564B67BE.5040001@redhat.com> Date: Tue, 17 Nov 2015 18:45:34 +0100 MIME-Version: 1.0 In-Reply-To: <874mgkh6f5.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 for 2.5] QEMU does not care about left shifts of signed negative values List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , Laszlo Ersek , qemu-devel@nongnu.org On 17/11/2015 18:39, Markus Armbruster wrote: > The kernel switched from -fwrapv to -fno-strict-overflow in '09, because > -fwrapv was buggy in gcc 4.1 (already old then, completely irrelevant > now), and because it "seems to be much less disturbing to gcc too: the > difference in the generated code by -fno-strict-overflow are smaller > (compared to using neither flag) than when using -fwrapv", which may or > may not be still the case with compilers that matter today. > > Could you briefly explain why you picked -fwrapv and not > -fno-strict-overflow? Because -fno-strict-overflow doesn't silence ubsan, only -fwrapv does (it doesn't silence it for negative left shifts, but I've asked on gcc-patches whether they'd like to have that fixed as well). In the meanwhile I got some good news from the GCC folks: >> I think we should remove the ", but this is subject to change" in >> implement-c.texi (while replacing it with noting that ubsan will still >> diagnose such cases, and they will also be diagnosed where constant >> expressions are required). Paolo