Fortran IO structure - compiler vs. library

[Steve Ellcey]

jvdelisle@verizon.net wrote:

> 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.

Do you know if the 4.5 ABI breakage would include getting rid of the
st_parameter_44 and st_parameter_43 structures and the union of them
in st_parameter_dt?

I ask because I think the 'right' way to fix PR 37839 for 4.4 would
be to modify ioparm.def in the compiler to more accurately reflect
how st_parameter_dt is actually defined in the library.  Right now
we have:

IOPARM (dt,      common,        0,       common)
IOPARM (dt,      rec,           1 << 9,  intio)
IOPARM (dt,      size,          1 << 10, pintio)
IOPARM (dt,      iolength,      1 << 11, pintio)
IOPARM (dt,      internal_unit_desc, 0,  parray)
IOPARM (dt,      format,        1 << 12, char1)
IOPARM (dt,      advance,       1 << 13, char2)
IOPARM (dt,      internal_unit, 1 << 14, char1)
IOPARM (dt,      namelist_name, 1 << 15, char2)
IOPARM (dt,      id,            1 << 16, pint4)
IOPARM (dt,      pos,           1 << 17, intio)
IOPARM (dt,      asynchronous,  1 << 18, char1)
IOPARM (dt,      blank,         1 << 19, char2)
IOPARM (dt,      decimal,       1 << 20, char1)
IOPARM (dt,      delim,         1 << 21, char2)
IOPARM (dt,      pad,           1 << 22, char1)
IOPARM (dt,      round,         1 << 23, char2)
IOPARM (dt,      sign,          1 << 24, char1)
IOPARM (dt,      u,             0,       pad)

Which makes the compiler think id, pos, asynchronous, blank, decimal,
delim, pad, round, sign, and u are fields of the st_parameter_dt
structure.  But actually, they are fields of the st_parameter_44
structure which is in a union that is part of the st_parameter_dt
structure.  This has layout implications because the st_parameter_44
structure may need padding in front of it to be properly aligned and
thus having them in a structure causes them to be placed differently
then if they were just individual fields of dt.

Now we could probably ignore the union part and just tell the compiler
that there is a st44 structure which, like the common structure, is in
dt and that should fix the layout problem, but there would have to be a
bunch of code in trans-io.c that would also need to be changed to handle
the intermediate structure as well.  So I am thinking of a ioparm.def
file that looks something like this:

IOPARM (st44,    id,            1 << 16, pint4)
IOPARM (st44,    pos,           1 << 17, intio)
IOPARM (st44,    asynchronous,  1 << 18, char1)
IOPARM (st44,    blank,         1 << 19, char2)
IOPARM (st44,    decimal,       1 << 20, char1)
IOPARM (st44,    delim,         1 << 21, char2)
IOPARM (st44,    pad,           1 << 22, char1)
IOPARM (st44,    round,         1 << 23, char2)
IOPARM (st44,    sign,          1 << 24, char1)
IOPARM (st44,    u,             0,       pad)

IOPARM (dt,      common,        0,       common)
IOPARM (dt,      rec,           1 << 9,  intio)
IOPARM (dt,      size,          1 << 10, pintio)
IOPARM (dt,      iolength,      1 << 11, pintio)
IOPARM (dt,      internal_unit_desc, 0,  parray)
IOPARM (dt,      format,        1 << 12, char1)
IOPARM (dt,      advance,       1 << 13, char2)
IOPARM (dt,      internal_unit, 1 << 14, char1)
IOPARM (dt,      namelist_name, 1 << 15, char2)
IOPARM (dt,      st44,          0,       st44)

But before I consider going down this road and try to fix up trans-io.c
to handle this ioparm.def setup I was wondering if, in the next release,
st44 was going to go away and thus all this work would have to be ripped
out again.

Steve Ellcey
sje@cup.hp.com