Derived Type stream I/O

[Reto_S_]

Dear Intel Support Staff

I'm using ifort 14.0.1 on ncar yellowstone (x86_64 linux) and have to read a binary header consisting of nested derived types. This works fine for gfortran but not for ifort. With ifort there are several bytes being added during the read. I've been able to write a very short sample code, where a single byte and a short integer is written in the form of a nested derived type with stream access. This is a total of 3 bytes.

The file position with gfortran is 4 (3 bytes written), with ifort it is 5 (4 bytes written).

Can you reproduce that? What is your solution to this for ifort? Can I possibly use a compiler directive so that I/O is byte-by-byte without adding additional padding bytes to the derived types?

Reto

[Lorri_M_Intel]

You could try either -noalign or  -align norecord

You will get a compile-time warning about potential misalignments, but it's just a warning.

            --Lorri

[Reto_S_]

Thanks Lorri

I've successfully tried these (which means: all work!):
- noalign
- align norecords
- SEQUENCE attribute to all derived types

In order to not mess with general alignment in the rest of the code I've decided for the SEQUENCE attribute.

In all three cases I get those warnings at compile time without problems during runtime:
- warning #6379: The structure contains one or more misaligned fields.
- warning #6380: The structure length is not a multiple of its largest element; could create misalignments for arrays of this type. 

Any chances that I'm messing up something here?

Reto

[Steven_L_Intel1]

I think that -noalign or -align norecords makes the most sense here. SEQUENCE works, but there's nothing in the language that requires it to do so. I was a bit astonished to find that adding BIND(C) to the types didn't pack the type, but maybe C wouldn't either - I'll have to test that.

[Reto_S_]

I have actually not tried BIND(C) yet, but will do so. To my understanding, BIND(C) does not guarantee no padding between derived type elements, it just guarantees that the fortran padding is equal to the C padding, right? However, do C compilers add padding to structure elements?

So, the only compiler-independent way of reading byte-by-byte structures (or derived types) is to read them element by element, right?

Reto