Unformatted and buffered file I/O

[Alexander_S_2]

I am having a hard time figuring out what the problem with my file I/O subroutine is. I am trying to use "unformatted" form and "buffered" writes to write large result files in one of my applications that are then read in another application. I was able to extract a minimal working example to reproduce the issues I have:

PROGRAM test
    
    implicit none
    
    INTEGER(KIND=4) :: dummy_int4, i, j
    INTEGER(KIND=4), DIMENSION(:,:), ALLOCATABLE :: array
    
    open(unit=20, file='debug.dat', status='replace', action='write', form='unformatted', buffered='yes')
    
    allocate(array(50000,26))
    
    do j=1, 26
        do i=1, 50000
            array(i,j) = i*j
        end do
    end do
    
    dummy_int4 = 1
    write(20) dummy_int4
    dummy_int4 = 2
    write(20) dummy_int4
    
    do j=1, 26
        write(20) array(:,j)
    end do
    
    close(unit=20)
    
    open(unit=20, file='debug.dat', status='old', action='read', form='unformatted', buffered='yes')
    
    read(20) dummy_int4
    write(*,*) dummy_int4
    read(20) dummy_int4
    write(*,*) dummy_int4
    
    close(unit=20)
    
END PROGRAM test

The output of the program in this version  is:

./a.out
           1
       49997

Which is not what I would expect. Changing the file opening clauses to buffered='no' yields the expected output 1 and 2. Where exactly am I going wrong here?

Intel fortran compiler version 17.0.4, Opensuse 42.2, Linux kernel version 4.4.87-18.29-default

[mecej4 · Accepted solution]

This is probably the same problem as discussed in the thread https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/721914 for Windows versions of the same compilers.

[Alexander_S_2]

Thanks for pointing me in the right direction. I tried again with version 18.0.0 and get the behavior I expected.

Two times I post an issue here in years, two times it turns out to be a compiler bug. I am obviously trying way too hard before asking for support.

[mecej4]

You are doing fine! The fact is that, over about six months, Intel has been urging users that bug reports should be made through the support channel instead of through these forums. I have mixed feelings about that shift.

This thread is an example where an ordinary user (me) remembered having (recently, by coincidence) seen a similar bug report, and spotted the similarity. I did not need a database of DPR numbers; I did not even have to search.

I wonder if a similarly fast response would have come from your going through the support channel. I have the advantage of being able to offer suggestions/answers that could be wrong, caveat lector, without being held responsible. Had the Windows bug report been made only through the support channel, neither you nor I would have known.

[jimdempseyatthecove]

>>The fact is that, over about six months, Intel has been urging users that bug reports should be made through the support channel instead of through these forums. I have mixed feelings about that shift. This thread is an example where an ordinary user (me) remembered having (recently, by coincidence) seen a similar bug report, and spotted the similarity. I did not need a database of DPR numbers; I did not even have to search.

I fully concur. The DPR (assuming you can search and locate same or similar bug), will not contain user responses as to a work around. Response time by Intel will be better at DPR. Therefor, posting in both places would be advised.

Intel, if you read this, it would be really handy to cross-link the two websites. This would permit users entering IDZ to easily post a DPR, as well as users entering DPR to go back to the (correct) forum to search for a work around.

Jim Dempsey