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 compiler make assumptions about alignment and avoid using those features, and work around them, etc., etc.
In my opinion, a memory allocator which does not return unaligned addresses is ignoring the ABI standard and therefore is at fault, not MPIR. Bill. 2009/12/21 Dan Grayson <d...@math.uiuc.edu>: > 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 have seen a misalignment crash instead of > a wrong answer. > > Here's one possible fix that has just occurred to me. Another poster > suggested that the purpose of the instruction "and r9,-16" was to take > a presumed 8-byte aligned address and make it 16-byte aligned. Change > it to "and r9,-9". That adds 7 to the number, making a mask that > preserves the bottom three bits and thus any 8-byte misalignment, > maybe prompting a crash in a later instruction, or maybe making it > give the right answer if the hardware doesn't mind the misalignment. > > By the way, could mpir be written to be faster if memory allocators > all returned 16-byte aligned data? It seems to be the case for this > routine. > > On Dec 20, 2:50 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >> 2009/12/20 Dan Grayson <d...@math.uiuc.edu>: > ... >> > What about installing a test under "make check" that tries all >> > routines with misaligned limbs? Let the misalignment vary. Declare a >> > routine to "pass" if it gives the correct answer or crashes or aborts >> > the program. Declare the routine to "fail" if it gives an incorrect >> > answer. That would have caught the lshift routine I reported. There >> > might be some discussion about whether that behavior of mpn_lshift >> > counts as a bug. >> >> I'm not sure I completely understand. We already know that lshift will >> return the wrong answer if the limbs are unaligned (as your example >> demonstrated). It isn't designed to work with unaligned limbs. > > -- > > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
