Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28445 Discussions

Endian problem on derived type data reading/writing

xuzheng97
Beginner
403 Views

Hi,

Recently I meet a problem that ifort can not read file correctly with derived type definition I/O list.
Finally I found it is an endian related issue.
Ifort will handle derived type definition in little_endian and big_endian mixed mode when you set big_endian.

I used following example program to describle.
This program is to output an array and a derived type with same value.

module con_data
type con_d
sequence
real*8 :: a1
end type con_d
type(con_d) :: c_c
end module con_data

program test
use con_data
real*8 a(1)

c_c%a1=0.001
a(1)=0.001

open(10,file="out.array.big",form="unformatted",convert="big_endian")
open(11,file="out.type.big",form="unformatted",convert="big_endian")
open(12,file="out.array.little",form="unformatted",convert="little_endian")
open(13,file="out.type.little",form="unformatted",convert="little_endian")
write(10) a
write(11) c_c
write(12) a
write(13) c_c
close(10)
close(11)
close(12)
close(13)
end

Ifort version here is 12.1.0.233
I used 'ifort -extend-source 132 test.f' to do simple compilation.
And use 'od -v -t x1' to dump output files and get following data.

out.array.big 0000000 00 00 00 08 3f 50 62 4d e0 00 00 00 00 00 00 08
out.type.big 0000000 00 00 00 08 00 00 00 e0 4d 62 50 3f 00 00 00 08
out.array.little0000000 08 00 00 00 00 00 00 e0 4d 62 50 3f 08 00 00 00
out.type.little0000000 08 00 00 00 00 00 00 e0 4d 62 50 3f 08 00 00 00

Then first 4 bytes and last 4 bytes are supplementary bytes for sequential access mode.
Central 8 bytes are real data.

Look at second one, a derived type output with big endian.
Supplementary bytes are in big endian while central 8 bytes are in little endian.
Others seem to be normal, all in big endian or little endian.

Could any one help me on this?
Many thanks

0 Kudos
4 Replies
mecej4
Honored Contributor III
403 Views
Here is what GFortran gives:

out.array.big : 0000000 00 00 00 08 3f 50 62 4d e0 00 00 00 00 00 00 08
out.type.big : 0000000 00 00 00 08 3f 50 62 4d e0 00 00 00 00 00 00 08
out.array.little : 0000000 08 00 00 00 00 00 00 e0 4d 62 50 3f 08 00 00 00
out.type.little : 0000000 08 00 00 00 00 00 00 e0 4d 62 50 3f 08 00 00 00

I wonder how the output would have been if the derived type had two or more components.

By the way, what you call "bits" are "bytes".
0 Kudos
xuzheng97
Beginner
403 Views
Yes, they should be "bytes". Thanks for remind :-)

Gfortran seems to be correct as I tested on AIX platform.

Why Intel fortran handle deriverd type in such a strange way?

I tested with 3 elements 0.001 0.002 0.003.

out.array.big:
0000000 00 00 00 18 3f 50 62 4d e0 00 00 00 3f 60 62 4d
0000020 e0 00 00 00 3f 68 93 74 c0 00 00 00 00 00 00 18

out.type.big:
0000000 00 00 00 18 00 00 00 e0 4d 62 50 3f 00 00 00 e0
0000020 4d 62 60 3f 00 00 00 c0 74 93 68 3f 00 00 00 18
0 Kudos
eide
Beginner
403 Views
Hi,

I had a similar problem see -> http://software.intel.com/en-us/forums/showthread.php?t=73854

maybe convert='big_endian' in connection with derived type constructs is not implemented for binary io yet.


Eide
0 Kudos
Steven_L_Intel1
Employee
403 Views
Our implementation does not do conversion of derived type components. This made sense when we implemented this in the 1980s with the VAX FORTRAN STRUCTURE/RECORD extension that could include UNIONs, but perhaps makes less sense today. It's on our "wish list".
0 Kudos
Reply