On Dec 10, 9:13 pm, Dan Grayson <d...@math.uiuc.edu> wrote: > Well, Macaulay2 comes with thousands of tests, and only one failed, > deep inside a D-modules computation. It took a lot of single stepping > to figure it out. Part of the problem is that we have two custom > memory allocators, Boehm's gc and one copied from Singular-Factory > long ago. The latter is used just when calling routines in the > Singular-Factory library (it's fast), which doesn't happen that often.
I think that the one being used is omalloc (omalloc.c), which seems to default to 4 byte alignment, which is now wrong on Windows x64 at least. I notice that this allocator may also be used in Sage (William was involved in getting its license changed). I don't think it would be hard to update this allocator to match current architetcture requirements by increasing its default block alignment. But it also has the ability to deliver aligned memory with memalign (alignment, size) in place of malloc(size). If only malloc() and free() are being used - not realloc() - it _might_ be possible to use something like: #define malloc(x) memalign(ALIGN, x) with ALIGN as 8 or 16 as a quick fix (provided this definition can be suitably localised).. Brian -- 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.
