Fortran IO structure - compiler vs. library

[jvdelisle@verizon.net]

sje@cup.hp.com wrote:
> 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.

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

Yes, I believe you are correct.  It should be GFC_INTEGER_4 in io.h.  I 
will fix that unless someone suggests why it should be the larger type 
integer.
>
> 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?

I can't think of a way to account for this at the moment.

Jerry