I don't see how your "make check" routine could ever even come into contact with my custom allocator. Also, it's probably not worth your while to try to distinguish a custom allocator from your native allocator at run time, as it will waste time.
I suggest checking every pointer returned by the allocator for alignment if the compile-time DEBUG flag is defined. (For Macaulay2, I debug with that on.) The checking should happen in any routine that calls the allocator, and could be implemented by a single macro. 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. On Dec 10, 4:20 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > Hi Dan, > > indeed I had inferred that you had done a *lot* of work to track this bug > down. > > It's not immediately clear how we can cause an error message to be > output if a custom allocator returns non-aligned pointers. > > Two possibilities spring to mind: > > 1) Introduce a make check test which checks that the allocator is > doing what we want. But this relies on the allocator failing to do so > during the test, which I don't see how to provoke. > > 2) Introduce code to align data coming from custom allocators. This > could probably be done in a handful of cycles per allocation, but > would still introduce an overhead. > > I'm open to further suggestions. > > Bill. > > 2009/12/10 Dan Grayson <d...@math.uiuc.edu>: > > > That's a fine decision, but now it becomes super important to help > > developers discover that their custom allocator is breaking the rule, > > if it does. It took me many hours of single-stepping to discover it. > > It would have saved me a lot of time if the program had aborted with a > > suitable error message. > > > On Dec 10, 12:36 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > > >> Thus the very clear intent of the test code is that for n byte limbs, > >> only n byte aligned data is allowed. Thus the conclusion is clear. > >> There is no intention to support any other kind of alignment and so > >> the documentation must be changed. > > > -- > > > 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 > > athttp://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.
