From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZydMR-0001jK-DV for qemu-devel@nongnu.org; Tue, 17 Nov 2015 05:19:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZydMQ-0005jZ-GO for qemu-devel@nongnu.org; Tue, 17 Nov 2015 05:19:39 -0500 Received: from mail-vk0-x231.google.com ([2607:f8b0:400c:c05::231]:33280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZydMQ-0005jO-Cp for qemu-devel@nongnu.org; Tue, 17 Nov 2015 05:19:38 -0500 Received: by vkbq142 with SMTP id q142so2305201vkb.0 for ; Tue, 17 Nov 2015 02:19:37 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1447754381-29882-1-git-send-email-pbonzini@redhat.com> References: <1447754381-29882-1-git-send-email-pbonzini@redhat.com> From: Peter Maydell Date: Tue, 17 Nov 2015 10:19:17 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 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: Paolo Bonzini Cc: QEMU Developers On 17 November 2015 at 09:59, Paolo Bonzini wrote: > There's no reason for the compiler to exploit the undefinedness of left > shifts, In fact GCC explicitly documents that they do not use at all > all this possibility. They also say this is subject to change, but > they have been saying this for 10 years (since the wording appeared in > the GCC 4.0 manual). > > Any workaround for this particular case of undefined behavior uglifies > the code: using unsigned is unsafe because the value becomes positive > when extended; using -(a << b) does not express as well that the > intention is to compute -a * 2^N. > > Clang has just added an obnoxious, pointless, *totally useless*, unsafe > warning about this. It's obnoxious and pointless because the compiler > is not using the latitude that the standard gives it, so it just adds > noise. It is useless and unsafe because it does not catch the widely > more common case where the LHS is a variable, and thus gives a false > sense of security. I think we should only take this patch if you can get a cast-iron guarantee from both clang and gcc that they will never use this UB to drive optimizations. As you say gcc already say this more or less, but clang doesn't, and if they're warning about it that to me suggests that they will feel freer to rely on the UB in future. GCC is not our only supported compiler; UB is a real thing that compilers in general take advantage of; we should be trying to reduce our reliance on UB, not carving out extra areas where we feel free to use it. thanks -- PMM