(j3.2006) DOUBLE PRECISION and C Interoperability

[Malcolm Cohen]

On 09/05/12 18:41, Robert Corbett wrote:
> If a C companion processor imposes stricter requirements
> on alignment for objects of type double than a Fortran
> processor can guarantee for objects of type
> DOUBLE PRECISION, can C double and Fortran DOUBLE PRECSION

or Fortran REAL with the -double option.

> be considered interoperable types?

I don't think so, at least not entirely.

But let us examine each case separately - there are multiple cases...

Case 1: argument passing.

The only problem here would be if the C compiler generated code that got a 
hardware fault accessing the misaligned double (in the case where 
copy-in/copy-out was not available).  That is probably fudgeable by saying that 
the "companion processor" is the C compiler with the -xmisalign option (assuming 
there is such an option to permit access to misaligned data).

Case 2: Variables with BIND(C).

The Fortran compiler can simply align these itself.  Not a problem (in theory, 
anyway).

Case 3: BIND(C) types.

Two subissues
(a) alignment within the type of C_double variables; the Fortran compiler is 
free to align these correctly itself, indeed that is the primary reason we added 
BIND(C) types instead of re-using SEQUENCE!
(b) alignment of variables of BIND(C) types, either for argument passing or 
direct exposure via BIND(C); the compiler can simply ensure that such variables 
are aligned - it knows which ones they are.  If too lazy to do that, fall back 
on the -xmisalign requirement excuse.

Case 4: BIND(C) COMMON blocks.

The issue here is mostly (entirely?) with

subprogram X:
   Common/C/A,D,B
   Integer(C_int) A,B
   Real(C_double) D
   Bind(C) /C/

interoperates with extern struct { int A; double B; int B };

subprogram Y:
   Common/C/I,J,K,L
   Integer(C_int) I,J,K,L
   Bind(C) /C/

interoperates with extern struct { int I,J,K,L; };

There appears to be no escape clause from the usual storage association rules 
here, which means that both definitions of /C/ are consistent and that Y::L is 
associated with X::B.  If C double is 8-byte-aligned as one would naturally 
expect, it is impossible to satisfy both the interoperation identities and the 
storage association identity.

I don't see an obvious weaselling out of this one either, unless the C compiler 
has an option to pack structs (which it might well do, but then again might well 
not).  In which case the only successful weasel is going to be "program too 
complicated".

If I have not missed some requirement that would be violated by the last 
example, I would be sympathetic to considering some kind of technical change for 
BIND(C) COMMON, because we obviously already had it in mind to handle the 
"different padding" rules given that we actually have BIND(C) types: it looks 
like we failed here.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.