Re: [mpir-devel] Re: mpn_lshift alignment bug

2009-12-21 Thread Bill Hart
2009/12/21 Bill Hart : > 2009/12/21 Dan Grayson : >> Right.  The proposal would be to declare that a bug.  Then we would >> have to fix it.  Fixing it would mean rewriting mpn_lshift so it >> crashes or returns the right answer with misaligned limbs.  If it had >> been written that way in the first

Re: [mpir-devel] Re: mpn_lshift alignment bug

2009-12-21 Thread Bill Hart
x86_64 was introduced less than 10 years ago. It is likely that the assumptions you made then were valid then. Note that on 32 bit machines you only need 4 byte alignment. It is only the x86_64 ABI which requires alignment to 8 bytes. Bill. 2009/12/21 Dan Grayson : > The memory allocator provided

Re: [mpir-devel] Re: mpn_lshift alignment bug

2009-12-21 Thread Bill Hart
2009/12/21 Dan Grayson : > Right.  The proposal would be to declare that a bug.  Then we would > have to fix it.  Fixing it would mean rewriting mpn_lshift so it > crashes or returns the right answer with misaligned limbs.  If it had > been written that way in the first place, we wouldn't be having

Re: [mpir-devel] Re: mpn_lshift alignment bug

2009-12-21 Thread Bill Hart
sizeof(void *) will be fine on most systems including all the important ones we support, as MPIR usually tries to select a limb which is either long or long long depending on what is available, and this is the size of a pointer on all the important systems I am aware of. Bill. 2009/12/21 Dan Gray

Re: [mpir-devel] Re: mpn_lshift alignment bug

2009-12-21 Thread Bill Hart
But as I pointed out. Fixing this "bug" would mean more than rewriting lshift. We'd have to potentially rewrite all the functions in MPIR. Furthermore we'd have to rewrite the entire test suite to certify that each and every function obeyed these new rules. Then we'd have to figure out when the C c

[mpir-devel] Re: mpn_lshift alignment bug

2009-12-21 Thread Dan Grayson
The memory allocator provided with Singular-Factory is in the file libcfmem.a, and the routines are called getBlock, freeBlock, and reallocBlock. I copied the routines more than 10 years ago and continue to use the modified copy. I may even have destroyed 8 byte alignment then while optimizing it

[mpir-devel] Re: mpn_lshift alignment bug

2009-12-21 Thread Dan Grayson
Right. The proposal would be to declare that a bug. Then we would have to fix it. Fixing it would mean rewriting mpn_lshift so it crashes or returns the right answer with misaligned limbs. If it had been written that way in the first place, we wouldn't be having this discussion, because I would