topic Neil - The root cause was a in Intel® Fortran Compiler

13.0 compiler bug: file position not advanced after input data transfer

Neil_Carlson — Sat, 13 Oct 2012 19:07:14 GMT

The small attached program writes the string 'abcdefghijkl' (no trailing newline) to a file, opens the file for stream access, and reads the file in 8-character chunks into a character array buffer. While reading the second chunk the EOF is encountered. The read includes IOSTAT= to handle the EOF condition. What I expect to have happened is for the data preceding the EOF to have been successfully transferred into the initial elements of the buffer array and for the file position to have been advanced up to the EOF. This is the behavior I see with a number of compilers (NAG, GFortran, PGI), but the Intel 13.0 compiler behaves differently, and I believe incorrectly. While the appropriate data is transfered into the initial elements of the buffer array, the file position is not advanced. Here's the expected output of the program:

initial stream position= 1
reading into 8-character buffer...
current stream position= 9 , buffer length= 8
buffer=abcdefgh
reading into 8-character buffer...
current stream position= 13 , buffer length= 4
buffer=ijkl

Here's the output using the Intel 13.0.0 compiler:

I think this (incorrect) behavior may be based on a flawed understanding of 9.11.3 (3) which says in part, "If an end-of-file condition occurs during execution of an input/output statement that contains either an END= specifier or an IOSTAT= specifier, and an error condition does not occur then: if the statement is a READ statement [...] all input list items or namelist group objects in the statement that initiated the transfer become undefined". Each item in the input list initiates its own data transfer, in order, and each element of the buffer array is considered an effective item (see 9.6.3, par 7 (bullet 1) and par 8). Consequently, data transfer should have completed successfully for the initial elements of the buffer array and the file position advanced accordingly.

Thank you for the details and

Kevin_D_Intel — Mon, 15 Oct 2012 08:26:00 GMT

Thank you for the details and convenient reproducer. I reported this to our I/O developers (internal tracking id noted below) for further analysis. The behavior when built w/13.0 is not different vs. our earlier releases so at least the behavior noted w/13.0 is not new. I will keep you updated on what I hear from our Developers.

(Internal tracking id: DPD200237439)

(Resolution Update on 02/08/2013): This defect is fixed in the Intel Fortran Composer XE 2013 Update 2 (2013.2.146 - Linux)

Kevin-

Neil_Carlson — Mon, 15 Oct 2012 14:08:47 GMT

Kevin- I should have noted that according to 9.3.4.4.1 the file should have been positioned after the EOF after the read that encounters the EOF. This is regardless of how 9.11.3 is interpreted. It's clear from my reproducer that this isn't happening. -Neil

Thank you, Neil. I added your

Kevin_D_Intel — Mon, 15 Oct 2012 15:30:59 GMT

Thank you, Neil. I added your additional note to the internal tracking report.

Neil - The root cause was a

Kevin_D_Intel — Tue, 06 Nov 2012 16:37:00 GMT

Neil - The root cause was a run-time I/O library issue that I confirmed is fixed in our internal builds. I expect the fix will be in the next XE2013 update 2 (tentatively in late January). The program’s output when using our internal build is now identical with the expected output you noted earlier. Thank you again for reporting this defect.

This defect is fixed in the

Kevin_D_Intel — Fri, 08 Feb 2013 12:47:21 GMT

This defect is fixed in the Intel Fortran Composer XE 2013 Update 2 (2013.1.146 - Linux)