In our previous episode, Karoly Balogh (Charlie/SGR) said: > > > > Since the RTL's allocator is documented to align to 16 bytes, it's > > > definitely an issue also with Pascal code. We do have code where also > > > Pascal side triggers the aligment issue, but indeed, the main issue is > > > with linked C libs, depending on pointers from the Pascal side. > > > > I'm not an alignment expert, but only when loading types that are larger > > than the pointer size, since only those are not naturally aligned and so > > could cross cacheline bounderies? > > Yes, but the problem is, you have no idea what the underlying library > does, and GCC seems to compile code where it thinks it would be more > optimal which expects the malloc()-alike alignment at least.
My point exactly. If tomorrow GCC 5 changes to 32-byte alignment on intel, we are back to where we started. > > Anyway, I don't see a problem with having a cmemalign16 (or -32 or whatever) > > unit, but I wouldn't blow up allocation unnecessary if there hasn't been a > > real problem in most cases. > > Well, I would still fix the original cmem to not destroy the underlying > malloc alignment, but that patch should be much less invasive. Another > idea would be to add a simple helper to the RTL, to allocate/free an > aligned memory block, something libc already has, IIRC. So we provide multiple choices, and during problems people can fix their issues by changing unit. Administrating and releasing a holy default cmem in a target specific way is IMHO a bridge too far, though maybe make an exception for targets like x86_64 that really universally align to 16-byte. Attempting t odo so only provides a temporarily relief from alignment issues and triggers complaints from people that see their memory use increase (alignment + pointer) without having a problem in the first place. > > Since cmem is documented to be used from the main program file (iow the > > users code), that would nicely put the responsibility there. > > Yes, but this still doesn't answer the question why my cmem16 doesn't work > for complex apps, while it seems to pass all simple heap testcases. :) I assumed language helpers would access allocated size in Delphi. But then I can't understand why your code then wouldn't work, since size is still directly before allocation. > (On a slightly related note, did anyone run current trunk compiler with > cmem allocator through valgrind recently? I seem to get quite some "using > uninitialized memory" hits.) Not me. Last did that about 1.5 years ago just after 2.6.x to hunt fpdoc bugs. _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
