Here is the line of offending code:
nmlname = trim(tmppath)//EMsoftnativedelimiter//'test.nml'//char(0) open(dataunit, file=trim(nmlname), status='unknown', delim='apostrophe',iostat=istat)
When compiled in "Debug" mode (No optimizations) the code works as one would expect.
When I compile in "Release" mode I get the following run time error:
C:\Users\mjackson\Workspace\EMsoftPrivate-build\Release>Bin\HDFtextfileTest.exe nml file opened with iostatus 0 nml written with iostatus 0 writing filename = <C:\Users\mjackson\Workspace\EMsoftPrivate-build\Release\EMs oft\Testing\Temporary\HDFtest_nmlfile.h5>, has length 99 cstring : <C:\Users\mjackson\Workspace\EMsoftPrivate-build\Release\EMsoft\Testi ng\Temporary\HDFtest_nmlfile.h5 > has length 100 forrtl: severe (43): file name specification error, unit 55, file C:\Users\mjackson\Workspace\EMsoftPrivate-build\Release\EMsoft\Testing\Temporary\test.nml Image PC Routine Line Source libifcoremd.dll 00007FFF8695C77C Unknown Unknown Unknown libifcoremd.dll 00007FFF8698861E Unknown Unknown Unknown EMsoftHDFLib.dll 00007FFFA49AEC57 Unknown Unknown Unknown EMsoftHDFLib.dll 00007FFFA49AE1D4 Unknown Unknown Unknown HDFtextfileTest.e 00007FF712011851 Unknown Unknown Unknown HDFtextfileTest.e 00007FF712013CDD Unknown Unknown Unknown HDFtextfileTest.e 00007FF71201465B Unknown Unknown Unknown KERNEL32.DLL 00007FFFB9548364 Unknown Unknown Unknown ntdll.dll 00007FFFBBB35E91 Unknown Unknown Unknown
Note the unprintable characters at the end of the file path. I come from a C/C++ background and this was typically a sign that we did not null terminate our strings. The original author of the code swears that we do not need to null terminate strings in FORTRAN. This code also works just fine in GFortran.
Just looking for some clarification on whether I need to null terminate my character arrays that are really file paths?
This is on windows 10 with Visual Studio 2013 Update 5, IFort v17 Initial Release and CMake driven build.
Here are the standard Fortran Flags:
/W1 /nologo /fpp /libs:dll /threads /assume:byterecl
Added Debug flags:/Od /debug:full /dbglibs
Added Release Flags: /O2 /D NDEBUG
Thank you for any help or information that can be provided.
The file name on the open statement is not a C string the null termination is not needed. The trim() is also not needed as nmlname will be padded with white space and the open will ignore those.
Not sure what the crash is though, trim only removes whitespace so the null termination may be the cause of the problem.
Right, so just to be clear, in DEBUG mode, I do NOT have to add the //char(0) for the program to run
In RELEASE mode, I MUST add the //char(0) to the code for the code to run properly.
Is this a compiler bug? Optimization bug? Bad Code gen?
Post the source of a small reproducer, it is hard to know what the problem is without seeing some code.
Also try release build with optimisation switched off.
You should never nul-terminate strings passed to OPEN, and in fact doing so is an error. If it works in gfortran it's by accident.
Right. It FAILS with IFORT if I do NOT put the null-terminate character. Everyone agrees that this is WRONG but the fact is that if I leave it OFF then the OPEN call fails (when built with Optimization). The code works correctly when there is NO optimization.
! THIS CODE WORKS with GFortran and ifort in debug but fails ! with ifort in release. This is valid Fortran 2003 code nmlname = trim(tmppath)//EMsoftnativedelimiter//'test.nml' ! THIS CODE WORKS with ifort in Release mode nmlname = trim(tmppath)//EMsoftnativedelimiter//'test.nml'//char(0)
So I will assume this is an optimization bug in ifort?
I reserve judgement until I see a complete test case. My guess is that you have an uninitialized variable in there somewhere.