[GHC] #9806: malloc and mallocArray ignore Storable alignment requirements

[GHC]

#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