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
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
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
/*
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