On Thu, Mar 20, 2014 at 5:34 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote:
>
> Does this actually, in practice, result in miscompilation of this
> calculation in the kernel with some compiler or configuration? If so,
> this makes sense, but if not, what motivates putting this in stable?
It is _very_ easy for a compiler to turn
(long) a - (long) b < 0
into
(long) a < (long) b
because of the rule that signed arithmetic doesn't overflow (or
rather, the compiler can act as if it never does).
Now, arguably it's a silly thing to do on architectures like x86,
where code generation for those two expressions are basically
identical (it's a "cmp" followed by "js" or "jlt" respectively) but
some architectures don't necessarily have "jump on sign of compare
result", so ..
Alpha, for example, has a "cmplt", but if you want to get the sign
from the comparison you have to do a subtract (but then there is a
"branch if negative", so it ends up being more instructions only if
you turn it into a boolean value).
I don't actually remember of we had a case of compilers actually
mis-compiling it, but it is very believable. This is not one of those
"in theory, a compiler could ..." things that aren't really realistic.
It's very much a "a compiler could easily do it and it generates
better code on architecture xyz".
And once you do it because it generates better code on architecture
xyz, you might end up doing it on x86 just by mistake, since on x86 it
doesn't really matter and you might have done the simplifcation in
generic code..
Linus
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html