qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 2/9] QEMU does not care about left shifts of sign


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL 2/9] QEMU does not care about left shifts of signed negative values
Date: Wed, 25 Nov 2015 19:18:34 +0000

On 25 November 2015 at 17:50, Paolo Bonzini <address@hidden> wrote:
> On 25/11/2015 18:44, Peter Maydell wrote:
>> We still haven't had any response from the LLVM/clang folks that
>> this interpretation of the meaning of -fwrapv is their interpretation
>> of it, have we? (I can't see any comments on the referenced bug.)
>
> Reasonably, they will have to follow what GCC does, independent of
> -fwrapv.  GCC has now promised to not exploit << undefined behavior,
> even without -fwrapv.

I don't think that follows. If -fwrapv is still documented by gcc
as only affecting arithmetic and not shifts, I don't see any
reason why the llvm people will expect it do to anything else.
And LLVM is its own project and its developers don't always exactly
follow gcc behaviour.

Your latest patch at https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03055.html
doesn't seem to touch the documentation of -fwrapv at all, so I
don't think it is sufficient to allow users of the compiler
to say "-fwrapv means signed behaviour for shifts".

> So at this point, -fwrapv is only required to placate ubsan---which it
> will do for GCC as soon as my other patch is approved (I talked on IRC
> with one of the GCC-ubsan authors and he said he was okay).  clang with
> ubsan remains broken, but that's no worse than before.

I would rather see GCC's documentation explicitly state that
-fwrapv means a dialect where [among other things] shifts of
signed integers have 2s-complement behaviour, and ditto
clang, before we accept this patch. (Or at least have those
documentation fixes in the works.)

I don't mind if there are still unsuppressed warnings with
older compilers. What I want is a clear statement in the
docs for both compilers that -fwrapv gives us the semantics
we're trying to rely on.

thanks
-- PMM



reply via email to

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