qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] target-i386: Use 1UL for bit shift


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1/2] target-i386: Use 1UL for bit shift
Date: Thu, 1 Oct 2015 15:52:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0


On 01/10/2015 11:24, Peter Maydell wrote:
> On 30 September 2015 at 21:24, Richard Henderson <address@hidden> wrote:
>> On 09/30/2015 11:27 PM, Paolo Bonzini wrote:
>>> ps: Ego ceterum censeo that these warnings are useless and uglify the
>>> code unnecessarily.  But it looks like I'm in a minority so the patch is
>>> okay.
> 
>> I totally agree.  There are no ones-compliment machines anymore, and so the
>> whole point of that "undefined" in the C standard is moot.  Let's all accept
>> that shifts of signed quantities do exactly what we expect.
> 
> I'd rather not do that without a documented statement from both
> clang and gcc teams that they won't use this UB to do optimizations
> that might break programs relying on it. History suggests they
> will happily do so if it improves a benchmark at all.

Well, this is pretty much the only ubsan issue that we stumble upon.
You can imagine how common that is in the wild and how good a move that
would be to rely on that undefined behavior.

In addition, C89 didn't say at all what the result was for signed data
types, so technically we could compile QEMU with -std=gnu89 (the default
until GCC5) and call it a day.

Really the C standard should make this implementation-defined.

>> Without looking, I don't suppose either compiler has a switch to disable
>> just the shift part of ubsan?
> 
> Not without turning off other shift checks which we would want to
> retain (like shifts greater than the bitwidth), I think.

I agree those are valuable.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]