Peter Maydell <peter.mayd...@linaro.org> writes: > On 26 November 2015 at 11:23, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 26/11/2015 11:56, Peter Maydell wrote: >>> It makes a claim about the semantics that the compiler >>> guarantees us which isn't currently valid. (Or >>> alternatively, it's implicitly claiming that clang isn't >>> a supported compiler, which isn't true.) I don't think >>> we should document or rely on signed-shift semantics >> >> But we are relying on them, and thus we should document them. Witness >> the number of patches fixing so called "undefined" behavior. And those >> patches are _dangerous_.
I'm pretty sure us screwing some of them up is a much larger risk than gcc suddenly starting to screw up our signed shifts without anybody noticing. If gcc ever started to mess up signed shifts, I'd fully expect the kernel and many applications to go down in flames. Hopefully quickly enough to avoid real damage. I don't think gcc has become *that* reckless. Clang neither. > Until and unless the compiler guarantees us the semantics that > we want, then silently hoping we get something we're not getting > is even more dangerous, and avoiding the UB is better than > just crossing our fingers and hoping. The cost and risk of proactively fixing a hypothetical^Wlatent problem needs to be weighed against the probability of it ever becoming real. >> I can certainly remove the "as documented by the GCC manual" part and >> the -fwrapv setting, but silencing -Wshift-negative-value and >> documenting what we rely on should go in. > > I don't see much point in documenting what we rely on > if we can't rely on it and need to stop relying on it. "Can't" and "need" are too strong. The kernel can, and I fail to see what makes us so special that we absolutely cannot. For what it's worth, I'm sick and tired of patches "fixing" signed shifts, and the unnecessary risk that comes with them.
