From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1z3j-00074B-DV for qemu-devel@nongnu.org; Thu, 26 Nov 2015 11:06:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1z3f-00053h-65 for qemu-devel@nongnu.org; Thu, 26 Nov 2015 11:06:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1z3f-00053c-0H for qemu-devel@nongnu.org; Thu, 26 Nov 2015 11:06:07 -0500 References: <1448471956-66873-1-git-send-email-pbonzini@redhat.com> <5656E194.10609@redhat.com> <5656EBA3.90703@redhat.com> <56570348.3050409@redhat.com> <565727DF.7020209@redhat.com> From: Paolo Bonzini Message-ID: <56572DEB.5010808@redhat.com> Date: Thu, 26 Nov 2015 17:06:03 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On 26/11/2015 16:55, Peter Maydell wrote: > This is all talking about in-practice behaviour of the compiler. > What I'm interested in is what the documented guarantees are. They are these: >> Again, the _value_ is perfectly specified by the GCC documentation (an= d >> as of this morning, it's promised to remain that way). GCC leaves the >> door open for warning in constant expressions, and indeed GCC 6 warns >> more than GCC 5 in this regard. and they don't require -fwrapv at all. I only added -fwrapv for ubsan, but I now believe that C89 is a better way to shut it up. > I still don't understand why the GCC documentation can't straightforwar= dly > say "-fwrapv means you get 2s complement behaviour for all operations > including shifts and arithmetic, in all contexts, and we will not warn > or otherwise complain about it". If that's what they're in practice > agreeing to then why not just say so in a comprehensible way, rather > than splitting the information across two different sections of the > documentation and including a confusing bit of text about constant > expressions? Because for example -fwrapv still gives you a SIGFPE for INT_MIN / -1. >>>> This is about implementation-defined rather than undefined behavior,= but >>>> I think it's enough to not care about clang developer's silence. >>> >>> I disagree here. I think it's important to get the clang developers >>> to tell us what they mean by -fwrapv and what they want to guarantee >>> about signed shifts. That's because if they decide to say "no, we >>> don't guarantee behaviour here because the C spec says it's UB" then >>> we need to change how we deal with these in QEMU. >> >> No, we need to change our list of supported compilers (if that happens= ). >=20 > I would strongly favour avoiding this UB rather than dropping clang > as a supported compiler,and implicitly dropping OSX as a supported > platform. gcc supports OS X, but... > (But it doesn't seem to me very likely we'd end up having > to make that awkward choice.) ... to me neither. Also, if we had to make the choice, it'd probably be a good idea anyway. :) Paolo