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 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.
