This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
- From: "mick at nag dot co dot uk" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Oct 2005 09:26:52 -0000
- Subject: [Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
- References: <bug-24261-10567@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from mick at nag dot co dot uk 2005-10-11 09:26 -------
Thanks - the problem is now fixed in 64-bit compilations. However, if I compile
try.f and sub.c with the -m32 flag, I still get memory allocated on 8-byte
boundaries rather than 16-byte. As Andrew said, this is down to the way
glibc malloc behaves. I see that the glibc folks have discussed this
before, also in relation to the use of SSE instructions, but don't intend
to change the way malloc works:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
After reading that discussion it's not entirely clear to me why there is
so much objection to 16-byte alignment, but whatever, it leaves me in the
position of having lots of SSE assembly code that I can only use from Fortran
by kludges like this:
allocate(workspace(1000))
if (is_on_16_byte_boundary(workspace)) then
call assembly_routine(workspace)
else if (is_on_8_byte_boundary(workspace)) then
call assembly_routine(workspace(3))
end if
Personally I think that the malloc in glibc should align to 16 bytes, but given
that it sounds like that's not likely to happen, another way might be for
gfortran to use memalign instead of malloc in its ALLOCATE routine.
--
mick at nag dot co dot uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24261