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: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/4] target-arm: fix various clang UB sanitizer warnings
Date: Mon, 09 Feb 2015 10:16:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Peter Maydell <address@hidden> writes:

> 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...

Incredibly bad tradeoff.  But what's really, truly inexcusable is
compilers smart enough to "optimize" working code into faster,
non-working code, yet not smart enough to tell us when they use their
undefined behavior license.  clang at least provides tools to give us a
fighting chance.

That said, I'm lukewarm about complicating working, straightforward code
to comply with the fine print of the standard unless there's evidence of
optimizers breaking it, without workable ways to suppress the
problematic "optimizations".  For what it's worth, the kernel uses
-fno-strict-aliasing -fno-struct-overflow.

Your option (1) "Drop the enum and just use old-fashioned #define
EC_AA64_BKPT 0x3cU" isn't too bad, though.

If Eric's option (5) "change the usage of the shifting macro" fully
solves the problem, I'd prefer it.

I've always wanted to be able to say things like "unsigned long enum".



reply via email to

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