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
