Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25)

[Paolo Bonzini <pbonzini@redhat.com>]

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 (and
>> 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 straightforwardly
> 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).
> 
> 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