#9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8627 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Yuras): This issue is wider then the one in `vector`. All the `Foreign` API that works with `Storable`, assumes alignment to be limited to the largest possible value for non-SIMD types. And `malloc` allocates memory block, suitable for any such `Storable` instance, that is why it ignores alignment. Note: `malloc` is implemented via C function with the same name, and the behavior is actually inherited from C standard lib, see [[http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html|here]]. To allow large alignments we need to use either `posix_memalign` or other platform specific API. It is important that `posix_memalign` returns a pointer, that can be deallocated via C function `free`, see [[http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html|here]]. But unfortunately portability might be an issue, see [[http://www.gnu.org/software/gnulib/manual/html_node/posix_005fmemalign.html|here]]. (Also it might be slower, but I didn't try it myself.) Other platform specific functions return pointers that can't be deallocated via `free` function from C stdlib. We can change `free` not to use the C `free` function. But that will break a lot of code that uses `free` to deallocate memory that comes from C, and uses `malloc` to allocate memory that will be deallocated in C via C function. Yes, that code is already broken, because it does silly things, but it is common enough to care. Also `realloc` will be problematic too, because the corresponding C function doesn't support unusual alignment. Probably other functions will break too. I'd propose to reclassify the issue to documentation bug. All SIMD code should use special API to allocate and deallocate memory. It is probably possible to fix `vector` to handle large alignments, but it will introduce inconsistency into API. Sorry for long comment, and please correct me if I'm missing something. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9806#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler