Re: [mpir-devel] mpn_lshift alignment bug

2009-12-10 Thread Bill Hart
I found the following in correspondence with Jason (I can't just ask him, as his internet seems to be offline at the moment): "Misaligned data will segfault on some arches and instructions eg K10 and lshift" So presumably he has assumed data is aligned on K10, written a fast version of the code f

Re: [mpir-devel] mpn_lshift alignment bug

2009-12-10 Thread Bill Hart
By the way, in the mean time, the following may be a workaround for you. As allocation on non-limb aligned boundaries will imply a performance penalty and throw off all the cycle counts for the highly optimised MPIR assembly functions anyway, you may as well use a default x86_64 build if your memo

Re: [mpir-devel] mpn_lshift alignment bug

2009-12-10 Thread Bill Hart
Hi Dan, Thanks for the report! I'm a little surprised that this bug was not picked up during testing. The try program specifically tests for all memory alignment possibilities. I'll have to look into why it was not picked up. Nonetheless, a bug is a bug. We'll sort this out before releasing MPIR

[mpir-devel] mpn_lshift alignment bug

2009-12-10 Thread Dan Grayson
/* Bug in mpir 1.2.1. This program demonstrates that mpn_lshift, as implemented on 64 bit intel machines by mpn/x86_64/core2/lshift.as, gives the wrong answer if the limbs are not aligned to an 8 byte boundary. The confusion in the code starts with these lines: and r9