Problem on accessing to big endian file with type/structure variable

[yoshi_taha]

Hello,

I use Intel Fortran 10.1 20070913 on RedHat Linux ES4.
And, I got a problem reading a big endian data file.

The option CONVERT='BIG_ENDIAN' works correctly, if I try to read data from the file specifying regular variables like,

INTEGER :: i
REAL(4) :: x
OPEN(10,ACCESS='DIRECT',RECL=256,STATUS='REPLACE',FORM='UNFORMATTED',CONVERT='BIG_ENDIAN')
READ(10,REC=1) i, x

However, when I use a type/structure variable, the option does not work.

TYPE def
INTEGER :: i
REAL(4) :: x
END TYPE def
TYPE(def) val
OPEN(10,ACCESS='DIRECT',RECL=256,STATUS='REPLACE',FORM='UNFORMATTED',CONVERT='BIG_ENDIAN')
READ(10,REC=1) val

Using other compilers like g95 and SunStudio, I did not got such endian problem.
Is it the ristriction of the Intel fortran?

The following the sample code I used.

!-- init
type DEF
sequence
integer :: i
real(4) :: x
end type DEF
type( DEF ) :: org, new

org%i = 37 ; org%x = 12.34
print *, 1, org

!-- write
open( 10, FILE = 'dat', ACCESS = 'DIRECT', FORM = 'UNFORMATTED', &
RECL = 256, STATUS = 'REPLACE', CONVERT = 'BIG_ENDIAN' )
write( 10, REC = 1 ) org%i, org%x
close( 10 )

!-- read
open( 20, FILE = 'dat', ACCESS = 'DIRECT', FORM = 'UNFORMATTED', &
RECL = 256, STATUS = 'OLD', CONVERT = 'BIG_ENDIAN' )
read( 20, REC = 1 ) new%i, new%x
print *, 2, new
read( 20, REC = 1 ) new
print *, 3, new
close( 20 )

Then, I got the results

1 37 12.34000
2 37 12.34000
3 620756992 -5.2100365E-17

[Steven_L_Intel1]

This is the documented behavior, and since we (as DEC) invented this feature back in the 1980s, it's the way we've done it ever since. The problem at the time had to do with UNIONs, which Fortran 90 derived types don't have.

Nowadays this behavior seems less reasonable, but we have not changed it yet. For now you will have to list the structure components individually.

[yoshi_taha]

Mr Lionel,

I usually refer to 'Intel Fortran Compiler Document' instead of 'Intel Fortran Compiler User's Guide'.

Looking into the User's Guide, I found the description as you said.

Using a type/structure variable for reading/writing is very convenient to change file data structure and format, and saves much developing cost.

I hope this function will be implemented in the Intel Compiler as well.

I like this compiler since runs so fast.

Anyway, I will modify my code as you suggested.

Thank you for your prompt reply.

[walterfmiller]

Quoting - Steve Lionel (Intel)

This is the documented behavior, and since we (as DEC) invented this feature back in the 1980s, it's the way we've done it ever since. The problem at the time had to do with UNIONs, which Fortran 90 derived types don't have.

Nowadays this behavior seems less reasonable, but we have not changed it yet. For now you will have to list the structure components individually.

Steve,

When I posed a similar question to Intel three weeks ago, I was told that the problem was resolved in the V11 Fortran Compiler (in beta at the time). However, your post and my experience with V11, Intel64, on IBM system using SUSE indicate it wasn't. Is my statement correct or am I doing something wrong?

Your suggestion is not pratical for my situation where I read in an array of 339 structure with 40 variables in it and write a structure out with 161 variables.

Thanks,

Walt

[Steven_L_Intel1]

Do you have a reference for your earlier inquiry? I am not aware that this behavior is changing.

[walterfmiller]

Quoting - Steve Lionel (Intel)

Do you have a reference for your earlier inquiry? I am not aware that this behavior is changing.

Steve,

It was Issue 521647 - convert big_endian compiler option. The response was from Steve Daily on October 30, 2008 at 9:46 PDT.

I reviewed problem reports on '-convert big_endian' and it looks like the new 11.0 compiler will have the fix for
this problem. This version of the compiler will be available soon but you can try out the beta version by signing
up at this web site

Thanks,

Walt

[Steven_L_Intel1]

Walt,

Thanks for the reference. I have asked the support engineer for the basis of his response - he may have been thinking of some different issue. Sorry for the miscommunication. As far as I know, we have no plans to change this behavior, though I will file it as a feature request.