On 25 November 2015 at 19:30, Paolo Bonzini <[email protected]> wrote: > > > On 25/11/2015 20:18, Peter Maydell wrote: >> And LLVM is its own project and its developers don't always exactly >> follow gcc behaviour. > > True. The patch documents that if LLVM will not respect 2s complement > for signed shifts when passed the -fwrapv option, it will not be > supported for compilation of QEMU. But let;s cross that bridge when we > reach it. So far, -Wshift-negative-value seems to be a misguided > attempt to copy GCC's warning without understanding it.
If we don't have documented support for a "signed negative shifts are valid and have these semantics" option from both our compilers, then we definitely should not be committing a patch which silences warnings about them. Instead we need to fix all the places in our code which rely on those semantics. >> 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". > > GCC *always* does signed behavior for shifts, even without -fwrapv. > I'll commit tomorrow the patch that promises that for the future. > > GCC does not need -fwrapv at all. Yes it does, because without -fwrapv it still wants to warn about them. We need to tell the compiler that we really do want a C dialect where they have specific behaviour and so no warnings are ever correct. By default (as documented, even with your patch) GCC just promises that it won't actually do undefined behaviour for signed negative shifts. (It doesn't even actually say what impdef semantics it does provide, and in practice the impdef semantics include "warn about this", which we don't want.) thanks -- PMM
