Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Internal formatted read, mixing Compiler version 9.1 and 2019.3 gives runtime error

Zeinert__Holger
Beginner
1,168 Views

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

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
1,168 Views

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

 

View solution in original post

0 Kudos
16 Replies
Steve_Lionel
Honored Contributor III
1,168 Views

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.

0 Kudos
mecej4
Honored Contributor III
1,168 Views

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.

0 Kudos
Zeinert__Holger
Beginner
1,168 Views

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

0 Kudos
Zeinert__Holger
Beginner
1,168 Views

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.

0 Kudos
Zeinert__Holger
Beginner
1,168 Views

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

0 Kudos
mecej4
Honored Contributor III
1,168 Views

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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,168 Views

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

0 Kudos
Steve_Lionel
Honored Contributor III
1,168 Views

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.

0 Kudos
andrew_4619
Honored Contributor II
1,168 Views

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.

0 Kudos
Zeinert__Holger
Beginner
1,168 Views

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!

0 Kudos
Zeinert__Holger
Beginner
1,168 Views

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?

 

 

 

0 Kudos
Steve_Lionel
Honored Contributor III
1,169 Views

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

 

0 Kudos
Zeinert__Holger
Beginner
1,168 Views

Thanks.

I filed the bug report.

0 Kudos
Devorah_H_Intel
Moderator
1,168 Views

This issue has been fixed in the next Intel Fortran Compiler 19.1 release.

0 Kudos
Sandhu__Nicky
Beginner
1,168 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
1,168 Views

It is fixed in the current release.

0 Kudos
Reply