On Fri, 3 Apr 2009, Gerd Hoffmann wrote: > > The whole point of the HALF_BITS thing is just to kill the gcc "hey your > shift is greater than bitsize of $type" warning, right? No, it's literally a corectness issue. If you do offset = ((loff_t) high) << BITS_IN_LONG; then that is literally undefined behavior in C (if "loff_t" and "long" are the same size), and a lot of C compilers will end up just optimizing it away entirely. Even if they don't optimize it away, and if they actually generate the instruction for it, architectures will not actually do what you think they do. At least on x86, shift counts are fundamentally limited to the low bits, so if you do movl $64,%ecx shlq %ecx,reg then an x86 will literally shift 'reg' by _zero_, because the count is masked by 6 bits (or 5, in the 32-bit case). So literally, if gcc were to generate the obvious (stupid) code, it would give the wrong value. With the double shift, we have well-defined behavior. > I really like it. Except for the low/high ordering it is basically > identical to the patch I've mailed. > > While hashing out all the issues I've learned alot about arch specific > ABIs. I can't see possible trouble spots and don't expect vetos from > arch maintainers. Ok, a few more ack's, and I can commit it. Anybody disagree? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
