On 25 November 2015 at 17:50, Paolo Bonzini <pbonz...@redhat.com> 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
