On 10/01/15 15:52, Paolo Bonzini wrote: > > > On 01/10/2015 11:24, Peter Maydell wrote: >> On 30 September 2015 at 21:24, Richard Henderson <r...@twiddle.net> wrote: >>> On 09/30/2015 11:27 PM, Paolo Bonzini wrote: >>>> ps: Ego ceterum censeo that these warnings are useless and uglify the >>>> code unnecessarily. But it looks like I'm in a minority so the patch is >>>> okay. >> >>> I totally agree. There are no ones-compliment machines anymore, and so the >>> whole point of that "undefined" in the C standard is moot. Let's all accept >>> that shifts of signed quantities do exactly what we expect. >> >> I'd rather not do that without a documented statement from both >> clang and gcc teams that they won't use this UB to do optimizations >> that might break programs relying on it. History suggests they >> will happily do so if it improves a benchmark at all. > > Well, this is pretty much the only ubsan issue that we stumble upon. > You can imagine how common that is in the wild and how good a move that > would be to rely on that undefined behavior. > > In addition, C89 didn't say at all what the result was for signed data > types, so technically we could compile QEMU with -std=gnu89 (the default > until GCC5) and call it a day. > > Really the C standard should make this implementation-defined.
Obligatory link: http://blog.regehr.org/archives/1180 :) >>> Without looking, I don't suppose either compiler has a switch to disable >>> just the shift part of ubsan? >> >> Not without turning off other shift checks which we would want to >> retain (like shifts greater than the bitwidth), I think. > > I agree those are valuable. > > Paolo >
