Mismatch between command line (ifort) vs. Visual Studio compilations

[Animesh_D_]

Windows - 10, Intel Parallel Studio XE 2016

I received this old legacy fortran source code (probably in Fortran-77) with a 72 column width scheme.

I am able to compile the code in command-line mode ( ifort <source>.f) and get an exe.

However, when I try to to create a console application using Visual Studio, I get all kinds of errors - syntax errors, line continuation errors, etc etc. Even after I fix them, I am unable to run the program.

My question is : is using the command-line version more forgiving? What is the difference between using the command line version and creating a console application using Visual Studio?

Finally, my colleague is using Mac and when he compiles the code using command-line option, the output results do not match what my output.

Can you please explain the possible causes of these discrepancies.

Thank you.

[TimP]

Taking a wild guess about what you didn't tell us, one of the differences is that automatic interface creation and checking is on under Visual Studio.   Interface errors could have a bearing on results not matching across platforms.

Since you mention continuation lines, the default treatment of .f .F and .for files should be consistent with f77 fixed format in either case.   The Visual Studio build log tries to show you the equivalent command line build options in effect.

[Steve_Lionel]

I'm going to take a different guess - rather than adding the .f file to the project, you did a copy-and-paste into a .f90 file. This would definitely cause the sort of syntax errors you describe.

[Animesh_D_]

Steve:

Thank you for your note. I actually added the orginal .f file to the project without any modification. I did not copy&paste into a .f90 file.

So I am still not sure why ifort is allowing me to compile the code successfully, yet a visual fortran console project throws up all kinds of errors. Also which is a more robust way to compile a project?
 

[Steve_Lionel]

Would you please ZIP the project directory, including source, and attach the ZIP here? You should not be having this problem.

[jimdempseyatthecove]

While the file extension will indicate a default source format, the project file may override this. To check

1) Navigate to the Solution Explorer
2) Expand the Project containing your .f file
3) Expand the Source Files
4) Right-click on problem some file
Configuration Properties | Fortran | Language | Source File Format

This should read "Use File Extension", but it can also incorrectly specify "Use Free Format".

Jim Dempsey

[Animesh_D_]

Dear Jim:

Appreciate the tip. The Source File Format setting was set to "Use File Extension".

I was finally able to compile the Visual Fortran project. However, when I execute the project in Debug mode -  I run into errors. I am attaching some screen shots and a log of the messages from visual studio.

However, when I compile in the command line mode, I am successfully able to complete running the exe file. It produces an output file as expected.

Why is the Visual Studio project throwing up errors whereas the command line version is able to run without any problems?

Thank you.

[Steve_Lionel]

Ok, this I can explain.

First, in the debug output, all of those "Loaded" messages are just the debugger telling you which EXEs and DLLs it loaded and whether or not they had debugging information. You can ignore this. You don't see these from the command line because you're not running under the debugger!

The run-time message is an array bounds error. The default settings for a Debug configuration in Visual Studio enable some compile-time and run-time checks that a simple "ifort" command on the command line do not. So when the program runs from a command-line build, there is no checking of array and string bounds so the erroneous reference to FFNU(21), when it is declared (20), goes unnoticed. This might lead to incorrect results.

I would say that the Visual Studio configuration is doing you a favor by identifying an error in your code.(at line 13666 in landingwear.f). You should investigate this and correct the problem.

[jimdempseyatthecove]

I concur with Steve "You should investigate this and correct the problem". While your program completes, and produces results, the expected results may or may not be correct. The array index out of bounds may (or may not) have affected the results... for this set of test data. IOW you program may be running correctly by chance, or has been producing consistent incorrect answers all along. Investigate thoroughly, simply increasing an array bounds, or reducing an iteration count, may not be the correct way to resolve the issue.

Jim Dempsey