See http://gcc.gnu.org/ml/fortran/2008-10/msg00105.html
Steve Ellcey writes there:
While examining the failures of some of the f2003 IO tests on my
IA64 HP-UX systems I found what I think is a mismatch between the
st_parameter_dt in the library and in the compiler. It seems like this
would affect f95 as well as f2003 so I am not sure why it hasn't shown
up before but I wonder if this is also why some of these tests fail on
powerpc too.
The first field in st_parameter_dt structure is common and is of type
st_parameter_common. This structure, in my ILP32 runtime mode is 28
bytes long (5 ints and 2 pointers). The second field in st_parameter_dt
is rec, which is type GFC_IO_INT. Now my ILP32 system does support 8
byte integers (as long long) so GFC_IO_INT is an 8 byte integer and that
in turns requires an 8 byte alignment. Since the first field is not a
multiple of 8 bytes the compiler puts 4 bytes of padding between common
and rec in the st_parameter_dt structure. I do not believe this padding
is accounted for in the compilers calculation of offsets as generated
from ioparm.def.
While investigating this problem I also noticed that there seems to
be a descrepency in the type of id in st_parameter_44. In io.h it is
"GFC_IO_INT *id" but in ioparm.def we have:
IOPARM (dt, id, 1 << 16, pint4)
Shouldn't io.h be GFC_INTEGER4 or perhaps ioparm.def should be pintio?
I don't think this problem is related to my problem though since it
would be a pointer and 4 bytes long in either case.
Is there a way to account for compiler padding in the st_parameter_dt
structure?
----------------------------------------------------------------------
Jerry replied:
We can not touch that part of st_parameter_dt without breaking ABI. Now for 4.5
we will probably break ABI for other reasons and this will be the opportunity
to do some re-constructive surgery. We could at that time make sure we align on
8 byte boundaries and pad if we have to. I do not know a way to magically do
this.
--
Summary: Fortran IO structure - compiler vs. library
(libgfortran) [requires ABI breaking?]
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37827
