- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
in a project, we use DLLs from different sources. One of them is compiled using Intel Fortran 9.1. It is integrated into a main program and other code compiled with Intel Fortran 2019.3. In the end, the program runs with just the runtime of Fortran 2019.3.
The code compiled in version 9.1 does an internal formatted read like this:
DOUBLE PRECISION A CHARACTER*15 STRING INTEGER TMPEXP A = 3.1415 WRITE(STRING(1:13),'(SP,E13.6)') A
The next line causes a runtime error:
READ (STRING(11:13),'(I3)') TMPEXP
forrtl: severe (268): end of record during read, unit -5, file Internal Formatted Read
This runtime error only happens within the code compiled in version 9.1 and using the runtime DLL libifcoremd.dll of version 2019.3. Previous runtime versions more recent than 9.1 did work fine.
Is there a way to get this to work?
For completion, I've attached an example of a C main program that calls the Fortran subroutine, including the build commands. If the Fortran file is compiled with 9.1 and when running with the runtime of 2019.3, there is the runtime error.
Regards
Holger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The /f77rtl is indeed the key here, but I think it is misbehaving.
The relevant difference in behavior is that if this is specified, PAD='NO' is in effect. This means that if the record doesn't contain enough characters, you'll get an error. But I don't see that being relevant here - the "record" has three characters and the format consumes three characters.
I suggest that you report this to Intel using the orange Bug Report button at the top of the main forum page. I'll comment that you don't need the C program to test this:
SUBROUTINE FFTEST DOUBLE PRECISION A CHARACTER*15 STRING INTEGER TMPEXP A = 3.1415 WRITE (*,*) 'A set to:' WRITE (*,*) A WRITE(STRING(1:13),'(SP,E13.6)') A WRITE (*,*) 'A formatted into string:' WRITE (*,*) STRING WRITE (*,*) STRING(11:13) READ (STRING(11:13),'(I3)') TMPEXP WRITE (*,*) 'Exponent read:' WRITE (*,*) TMPEXP WRITE (*,*) 'Finish' END CALL FFTEST END
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your project in the .7z builds and runs fine for me using 2019.0.4. You do have lots of compile options specified that are no longer (or never were) supported, but they are ignored.
D:\Projects\FortranTest\64bit>FortranTestC64.exe A set to: 3.14149999618530 A formatted into string: +0.314150E+01 Exponent read: 1 Finish
An end-of-file error on an internal read indicates that the READ attempted to fetch a new "record" (array element if an array), or ran off the end of the string. I don't see that happening in your test case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I built the EXE and DLL using 2019.0.4 (64-bit), but then opened a plain command window and set the path so that the old libifcoremd.dll and libmmd.dll provided by Holger were the only ones accessible to the EXE. It ran without error. I suspect that the third party DLL that was compiled with the old compiler has some other problem which we cannot reproduce, having neither the source nor the old version of the compiler available.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
thanks for testing. The problem I have is with a build using Fortran 9.1 and then using the 2019.3 Compiler runtime.
The project using 9.1 itself works fine, also the project that moved to the new 2019.3 compiler works fine, they use their corresponding runtime.
But when using obj or dll from 9.1 within the new project using 2019.3 and its runtime, then we have that strange runtime error.
I'll guess your tests just indicate that we have to make the old project move to the 2019.3 compiler as well. Or would you say that this is not likely the reason?
Mixing 9.1 obj/dll with a more recent Fortran runtime has worked before, though. Intel Fortran has show pretty stable in that regard.
Thanks
Holger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can I download the runtime of 2019.0.4 somewhere? Or can you attach it here? Then I can test my 9.1 program with this runtime.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK. I found the download of all runtime deliverables. I've tested my program compiled and linked in 9.1 with the different runtimes. It turns out that
- 2015.7 works
- 2018.5 works
- 2019.1 fails
- 2019.2 fails
- 2019.3 fails
- 2019.4 fails
I just would feel better if I would understand why 2019 starts to fail in this scenario. Upgrading code to a new compiler involves always a lot of testing and it would be a shame if it turns out to be a small compiler glitch.
The Release Notes of Intel Fortran 2019, Compatibility mention that
Compatibility
In general, object code and modules compiled with earlier versions of Intel Fortran Compiler (8.0 and later) may be used in a build with version 19.0. Exceptions include:
This seem to include my case using compiler 9.1. In the exceptions I did not find anything that seems applicable in my case.
Regards
Holger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is only your 32-bit EXE that crashes on my PC, but there is an additional twist that you have not encountered or noticed. The C RTL is also involved, and Microsoft made major changes to the C RTL a couple of years ago (definitely closer to 2019 than 2008). When I run your 32-bit EXE from the command line in the directory where it resides, the traceback is
libifcoremd.dll 734D3C25 Unknown Unknown Unknown libifcoremd.dll 7350DF3F Unknown Unknown Unknown libifcoremd.dll 7350BF27 Unknown Unknown Unknown FortranTestC32.ex 00C211B8 Unknown Unknown Unknown FortranTestC32.ex 00C21298 Unknown Unknown Unknown FortranTestC32.ex 00C21465 Unknown Unknown Unknown KERNEL32.DLL 75E96359 Unknown Unknown Unknown ntdll.dll 77727A94 Unknown Unknown Unknown ntdll.dll 77727A64 Unknown Unknown Unknown
However, if I run your 32-bit EXE inside the VS2017 debugger, the traceback changes to
libifcoremd.dll 505C3C25 Unknown Unknown Unknown libifcoremd.dll 505FDF3F Unknown Unknown Unknown libifcoremd.dll 505FBF27 Unknown Unknown Unknown ucrtbase.dll 74EE9497 Unknown Unknown Unknown <<<=== different FortranTestC32.ex 00BE1298 Unknown Unknown Unknown FortranTestC32.ex 00BE1465 Unknown Unknown Unknown KERNEL32.DLL 75E96359 Unknown Unknown Unknown ntdll.dll 77727A94 Unknown Unknown Unknown ntdll.dll 77727A64 Unknown Unknown Unknown
I don't think that it is reasonable to expect much interest in tracking this down. Most of us do not have IFort 9.x, and it is over a decade old. It is no longer available for downloading.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Holger,
RE #1, after you write the string(1:13) on line 6, print out the result in string. IOW the complete string(1:15).
Leftover junk in string(14:15) may be an issue
as well as "****" in string(1:13) should the output field be too small
as well as something else should string(1:13) be too small and "***" not inserted.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The program never touches string(14:15). If the value did end up writing asterisks, one would get a different error than EOF.
I had overlooked that the issue occurs only if you compile with 9.1 and then link to the newer libraries. I doubt you'll get anyone interested in tracking this down, and what are they going to do about it? Sometimes incompatibilities creep in unintentionally. The Intel Fortran team tries VERY hard not to break linking of old objects, as that was the philosophy at DEC. If you recompile with the current compiler, it seems to work ok.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Zeinert, Holger wrote:
Upgrading code to a new compiler involves always a lot of testing and it would be a shame if it turns out to be a small compiler glitch.
Bite the bullet an upgrade, hanging on to a 10+ year old compiler is not a real solution IMO, if you don't do it now you will still need to do it at some point in the future because there are always things to come back and get you..... just saying.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I understand that this might not be important. But since the compatibility covered down to 8.0, I just wanted to confirm that this is not something that might get fixed.
I will go ahead and upgrade to the newest compiler.
Thanks to everybody who tested/answered/contributed!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Me again. Sorry.
I got the new compiler (2019.3). We've compiled the test program with it, but it shows the same problem. No switching of runtime libraries, just the plain example.
When testing further, we removed the unused or not supported compiler flags. Then we compiled without the /f77rtl option (which is still supported), and then the program works fine. So, there is only a problem when using the /f77rtl option of the ifort command.
It also seems important that the Fortran code is called from a C main program.
Can this explain the behavior?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The /f77rtl is indeed the key here, but I think it is misbehaving.
The relevant difference in behavior is that if this is specified, PAD='NO' is in effect. This means that if the record doesn't contain enough characters, you'll get an error. But I don't see that being relevant here - the "record" has three characters and the format consumes three characters.
I suggest that you report this to Intel using the orange Bug Report button at the top of the main forum page. I'll comment that you don't need the C program to test this:
SUBROUTINE FFTEST DOUBLE PRECISION A CHARACTER*15 STRING INTEGER TMPEXP A = 3.1415 WRITE (*,*) 'A set to:' WRITE (*,*) A WRITE(STRING(1:13),'(SP,E13.6)') A WRITE (*,*) 'A formatted into string:' WRITE (*,*) STRING WRITE (*,*) STRING(11:13) READ (STRING(11:13),'(I3)') TMPEXP WRITE (*,*) 'Exponent read:' WRITE (*,*) TMPEXP WRITE (*,*) 'Finish' END CALL FFTEST END
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks.
I filed the bug report.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This issue has been fixed in the next Intel Fortran Compiler 19.1 release.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you! We have been frustrated with this error for a while and this post helped. We have clung to our previous working Intel compiler version and will upgrade only when Intel fixes this problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is fixed in the current release.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page