#2917: alloca and allocaArray do not respect alignment
---------------------------------+------------------------------------------
Reporter: guest | Owner: igloo
Type: merge | Status: new
Priority: high | Milestone: 6.10.2
Component: Compiler (FFI) | Version: 6.10.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Changes (by simonmar):
* owner: simonmar => igloo
* type: bug => merge
Comment:
`alloca` now aligns correctly according to the `Storable` instance, and
`allocaBytes` now aligns to 16 bytes. `malloc` and `mallocBytes` haven't
changed (yet). Perhaps we should use `posix_memalign` where possible.
Ian: please merge then bump to 6.12.
{{{
Thu Mar 5 07:41:53 PST 2009 Simon Marlow <[email protected]>
* Partial fix for #2917
Ignore-this: 3a06cd3ea09f1d6454d52031802a93fd
- add newAlignedPinnedByteArray# for allocating pinned BAs with
arbitrary alignment
- the old newPinnedByteArray# now aligns to 16 bytes
Foreign.alloca will use newAlignedPinnedByteArray#, and so might end
up wasting less space than before (we used to align to 8 by default).
Foreign.allocaBytes and Foreign.mallocForeignPtrBytes will get 16-byte
aligned memory, which is enough to avoid problems with SSE
instructions on x86, for example.
There was a bug in the old newPinnedByteArray#: it aligned to 8 bytes,
but would have failed if the header was not a multiple of 8
(fortunately it always was, even with profiling). Also we
occasionally wasted some space unnecessarily due to alignment in
allocatePinned().
I haven't done anything about Foreign.malloc/mallocBytes, which will
give you the same alignment guarantees as malloc() (8 bytes on
Linux/x86 here).
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2917#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
