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

Compile old fortran source code with modern Intel Fortran Compiler

v__vladimir
Beginner
3,365 Views

Hello everyone,

I have an old console application built with Lahey/Fujitsu Fortran 95 compiler. I want to compile these Fortran 95 source files with the Intel
Visual Fortran Compiler 19.0 and Visual Studio 2017. Unfortunately in Visual Studio appear 238 errors. What could be the reason and how to solve the issues properly?

One error is for example #6236: A specification statement cannot appear in the executable section.

I already found articles in which such a problem, to compile older source fortran files with modern compilers, is described. As a reason for those errors is declared that modern compilers are not compatible with old fortran standard.

I already searched for extensions, that fix the errors automatically but couldnt find something appropriate.

Thanks for hints and suggestions.
 

0 Kudos
30 Replies
Steve_Lionel
Honored Contributor III
545 Views

Intel Fortran supports all of those extensions from post #20 except DO UNTIL. (VALUE as a statement is supported as in Fortran 2003.) I would still like to see the build log.

0 Kudos
WSinc
New Contributor I
545 Views

I have an expired student license. Where can I go to renew it?

So far, no one has been able to tell me where.

0 Kudos
v__vladimir
Beginner
545 Views

Steve Lionel (Ret.) wrote:

Intel Fortran supports all of those extensions from post #20 except DO UNTIL. (VALUE as a statement is supported as in Fortran 2003.) I would still like to see the build log.

Hi Steve,

i can not post the buildlog because it contains source code. How I said it is an application of my University. Most of the files have an .f90 file extension, some have .f
No error in ifort appears for source code with .f file extension. If file extensions were renamed to .f90 I dont know.

But to read that those fortran extensions are supported by ifort is very pleasant. Can you tell me which options I have to enable to activate those extensions?

0 Kudos
andrew_4619
Honored Contributor II
545 Views

The build log "BuildLog.htm" does not have any source in it. It contains only the names of the source files and the options/commands used to build/compile/link and also any error messages. This will help people to help you!

If you rename  so any FIXED format fortran files to .for and and FREE format files to .f90 then the compiler will use the correct formatting and I think you will get less errors.

Extensions are enabled by default unless you override with specific options such as /stand:xxx which enforce standards fortran compliance/checking. 

 

 

0 Kudos
Steve_Lionel
Honored Contributor III
545 Views

The only source code in the build log is in error messages, and if you want us to help you we need to see those.

0 Kudos
v__vladimir
Beginner
545 Views

Big thanks for the support so far but the errors occur in almost each code line in the files that can not be compiled. So I would post with the buildlog a big part of source. Do you have maybe an idea in which section of the Intel Compiler options I have to change settings without seeing the buildlog? 

Compiling with Intel(R) Visual Fortran Compiler 19.0.3.203 [IA-32]... configuration 'Release|Win32'.
I have nothing changed in the options since installation of the Intel Compiler and Visual Studio.

I can post the part I have already posted in #6:

ifort /nologo /O2 /module:"Release\\" /object:"Release\\" /Fd"Release\vc150.pdb" /libs:dll /threads /c /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86" /Qm32 "C:\Users\xxx\Desktop\xxx\SRC\DATEN_EA\file.f90"

C:\Users\xxx\Desktop\xxx\SRC\DATEN_EA\file.f90(51): error #6404: This name does not have a type, and must have an explicit type.   [LASTFALL]

        WRITE(14,'(A,I2)',ADVANCE='YES',ERR=200) '  SPC =',lastfall

0 Kudos
gib
New Contributor II
545 Views

I asked how lastfall is declared.  You can answer that without revealing source code (although I don't understand your reluctance to post source code.)

0 Kudos
Steve_Lionel
Honored Contributor III
545 Views

Show us a different error message other than one about the type. Use the code tool in the toolbar (the one with {...}) to paste in the one line of source, from the source file, that it complains about.

You're hiding too much information for us to help you. It does no good for us to suggest random setting changes.

But for the LASTFALL error, you do need to prove to us that the variable is indeed declared. My guess is that it is not, and IMPLICIT NONE has been used.

0 Kudos
andrew_4619
Honored Contributor II
545 Views

How many source fortran files do you have? Is it by chance about 80 files?  The compiler aborts after a set number of errors, the default I think is 30 errors, so if you report 240 errors you must have at least 80 files.....

Sharing the compile errors from a build log  of a single source file does not constitute "sharing the source", what possible use could that be to anyone who wanted to steal IPR (not that anyone is likely to be interested in what is some old niche program)? It would allow people here to move forward with solving your problem. We are at post #30 of this thread and we are no nearer a solution than when we started.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
545 Views

Also

>>Compiling with Intel(R) Visual Fortran Compiler 19.0.3.203 [IA-32]... configuration 'Release|Win32'.

I suggest you shake out your build problems in Debug build with full compile time diagnostics enabled.

While you may see oodles of error messages and/or warnings, it will help you immensely in fixing errors in the program. Errors in coding, that had not shown up by crashing and old build, is (lack of crash) no indication that the old build was producing the correct results.

As an example, consider use of an uninitialized variable under an assumption that uninitialized is same as = 0.
Or, often, calling a subroutine with a DUMMY argument declared as an array larger than the array the caller supplies as an actual argument.

The above two errors in coding can often, not crash and present seemingly correct output.

Jim Dempsey
 

0 Kudos
Reply