I don't have the machines to test this on, but I think there is a chance of an alignment issue with in_pack / in_unpack.
Look at the following program: program main complex a(5),b(5) equivalence(a(1),r(1)),(b(1),r(12)) real r(100) a = (1.0, -1.0) b = (2.0, -2.0) call foo(a(5:1:-1),5) call foo(b(5:1:-1),5) end program main subroutine foo(arr,n) complex, dimension(n) :: a end subroutine foo The equivalence makes sure that a and b cannot both be aligned on an 8-byte-boundary. The array reference gets repacked for both calls to foo: parm.2.dtype = 545; parm.2.dim[0].lbound = 1; parm.2.dim[0].ubound = 5; parm.2.dim[0].stride = -1; parm.2.data = (complex4[0:] *) (complex4[0:] *) &equiv.0.a[4]; parm.2.offset = 0; D.529 = _gfortran_internal_pack (&parm.2); foo (D.529, &C.530); if (D.529 != parm.2.data) { _gfortran_internal_unpack (&parm.2, D.529); _gfortran_internal_free (D.529); } internal_pack_generic has the following code: size = GFC_DESCRIPTOR_SIZE (source); switch (size) { case 4: return internal_pack_4 ((gfc_array_i4 *)source); case 8: return internal_pack_8 ((gfc_array_i8 *)source); } so internal_pack_8 is called. This operates on a gfc_array_i8. On machines where you can only align an i8 on an eight-byte-boundary, this will fail. I'd appreciate if somebody could run the test program on such a machine, to see wehter I got this right :-) Thomas -- Summary: in_pack / in_unpack alignment issues Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21333