I have updated my compiler to the latest released fortran and compiled my code. Immediately I started getting crashes when reading unformatted sequential binary files; the complaint is that a record has too little data. My binary data files have not changed for a decade. Neither did the source code.
If I change the compilation of a source file that does the reading from /O3 to /Od the code runs fine. Reading the generated assembler I can see that the code is quite different between these, but without documentation for for_read_seq and for_read_seq_xmit I cannot find the bug myself.
I am using Fortran 16.0 Update 3, x64 code.
I can simplify this to a single file that demonstrates the problem. Please let me know what to do with it. (How/where to post, etc.)
Has anyone else seen such a thing?
I would like to get back to work without waiting for a new release to fix the problem. Turning off optimization is an obvious workaround, but I cannot afford to turn it off globally, and it would not be nice to have to change compile options on the dozens of individual source files that read binary data. I am wondering how far I should roll back the compiler...
From the description I'm fairly certain you have experienced this same issue, https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/640311. It was introduced in the PSXE 2016 Update 3 (16.0.3) release. A fix is expected in the PSXE 2016 Update 4 release tentatively scheduled for late-August.
You can attach the reproducer to a reply to this thread and we can check it out.
To avoid the issue you only need to roll-back one update to PSXE 2016 Update 2 (a.k.a. 16.0.2).
Our apologies for the inconvenience.
I have attached a program filetest.f. I compile it for x64 and link to static multithreaded libraries. I assume buffered_io. To be precise, here is the header from an asm listing:
; mark_description "Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Build 201";
; mark_description "60415";
; mark_description "-nologo -O3 -assume:buffered_io -module:x64\\Release\\ -object:x64\\Release\\ -Fdx64\\Release\\vc140.pdb -FA";
; mark_description "cs -Fax64\\Release\\ -libs:static -threads -c -extfor:f -Qlocation,link,C:\\Program Files (x86)\\Microsoft V";
; mark_description "isual Studio 14.0\\VC\\\\bin\\amd64";
Run it once with call writeit enabled. This will create the binary file. (I find the whole program succeeds when writeit is called.) Then recompile with !call writeit, i.e. the call commented out. At this point I find that /03 crashes with: forrtl: severe (67): input statement requires too much data, unit 28, file P:\chuckwh\testing\local\bintest. But a recompile with /Od runs to completion.
I have no idea if the specific record sizes are important, or if the implicit loops are important. This is already 99.9% simplified down from the original.
Thanks for your advice. I will install Update 2.
Thank you very much for the time/effort to create the reproducer. I confirmed this is another instance of the earlier cited issue.
I confirmed your test case fails only with the PSXE 2016 Update 3 release. It executes successfully with our PSXE 2016 Update 2 and our latest internal-only development compilers (both 16.0 and 17.0) containing the designated fix. Both the upcoming PSXE 2016 Update 4 (late-August) and PSXE 2017 initial release (later this year) will resolve the defect.