qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/4] target-arm: fix various clang UB sanitizer


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 0/4] target-arm: fix various clang UB sanitizer warnings
Date: Fri, 6 Feb 2015 17:48:02 +0000

On 6 February 2015 at 17:37, Eric Blake <address@hidden> wrote:
> On 02/06/2015 07:34 AM, Peter Maydell wrote:
> HACKING already implies we assume sane 2's complement behavior of shifts
> (maybe it's worth another line for this particular case of shifting into
> the signed bit of a signed result, and figuring out how to shut up clang):
>
>>> The C language specification defines regions of undefined behavior and
>>> implementation defined behavior (to give compiler authors enough leeway to
>>> produce better code).  In general, code in QEMU should follow the language
>>> specification and avoid both undefined and implementation defined
>>> constructs. ("It works fine on the gcc I tested it with" is not a valid
>>> argument...) However there are a few areas where we allow ourselves to
>>> assume certain behaviors because in practice all the platforms we care about
>>> behave in the same way and writing strictly conformant code would be
>>> painful. These are:
>>>  * you may assume that integers are 2s complement representation
>>>  * you may assume that right shift of a signed integer duplicates
>>>    the sign bit (ie it is an arithmetic shift, not a logical shift)

The difference is that these two are implementation-defined
behaviour, whereas shifting into the sign bit is undefined
behaviour.

I would much rather we had a well-defined and supported "friendly C"
dialect which actually did the things programmers expect C to do:
http://blog.regehr.org/archives/1180

In the absence of that we pretty much have to assume adversarial
optimization on the part of the compiler, because 0.5% improvements
in SPEC benchmark scores justify breaking previously working code...

-- PMM



reply via email to

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