On 6 February 2015 at 17:37, Eric Blake <ebl...@redhat.com> 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
