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
