[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25)
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25) |
Date: |
Thu, 26 Nov 2015 17:06:03 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
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
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), (continued)
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Peter Maydell, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Paolo Bonzini, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Peter Maydell, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Markus Armbruster, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Peter Maydell, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Paolo Bonzini, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Paolo Bonzini, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Peter Maydell, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Paolo Bonzini, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25), Peter Maydell, 2015/11/26
- Re: [Qemu-devel] [PULL 0/9] Misc patches for QEMU 2.5-rc2 (2015-11-25),
Paolo Bonzini <=