Fortran 16 fails at "contains"

[Laura_S_3]

Bottom line: I'm having problems getting a program to compile under Intel 16 Fortran and I suspect it isn't the code being flagged but is something elsewhere or compiler options.

I'm having problems getting Intel Fortran 16 to compile a rather large, proprietary program, so I can't post more than small snippets of code.This program compiles at least back to Intel Fortran 11, and probably further. The problems don't make sense, so I am wondering if the error messages are red-herrings and there actually is a different issue.

First output error messages:

        ifort -c -qopenmp -fpp -O2 -traceback -g -shared-intel -heap-arrays -fpe3 -qopt-report0 -DMKL -DMKL -DMKL -DMKL -DTHREADEDINTELMKL -I/p/home/apps/intel/compilers/16/compilers_and_libraries_2016.4.258/linux/mkl/include/intel64/lp64 -i4 -r8 -qopenmp -I. -I.. -I.././<directory name> -I.././<directory name> <file name>.f90
<file name>.f90(1235): error #6681: This is either an invalid statement, a declaration statement that is ordered incorrectly, or a null procedure statement.
contains
^
<file name>.f90(1252): error #6681: This is either an invalid statement, a declaration statement that is ordered incorrectly, or a null procedure statement.
end subroutine
^

Like I said, this compiles fine under previous versions, so the error doesn't make sense. I inserted an "endif" or an "enddo" before the "contains" to see if somehow it thought there was an unterminated block, but both of those were correctly flagged by the compiler as unpaired.

Later error messages in the contained subroutines include messages flagging local variable names in the contained routines. In the example below, i is locally declared within the subroutine.

<file name>.f90(3264): error #6405: The same named entity from different modules and/or program units cannot be referenced.  
         do i = 1, size(<array name>,1)
------------^

Anyone have any ideas? I spent several hours reworking code in what that looked to correct to last fall, and never got through all of the issues. (The one above was solved by turning the contained subroutines into not-contained ones, but then there were further issues, including OpenMP related ones.)

[Steven_L_Intel1]

You'll need to show us a compilable source that shows the problem. It could be a compiler bug or a source bug that went undetected in earlier versions. Have you tried version 17?

[Laura_S_3]

I'm not allowed to post the code (proprietary, etc), and even if I could, the module that is failing to compile has many thousands of lines of code spread across several files. In fact, one of my suspicions is that it is just too big and is triggering compiler bugs. However, if that were the only cause, I'd expect it to have been reported by many others, and I'm not seeing those reports. So I'm hoping that someone else has seen something similar and has insights on possible contributing factors.

[Laura_S_3]

Intel 17 - I haven't found it on the systems available to me at the moment (some are not currently available), but even if it compiles there, I expect to have to make it compile on 16 too.

[mecej4]

The usual action to take in a situation such as yours is to start with the large code (proprietary or not) and remove chunks of code, compiling after each excision to make sure that the error messages remain. There have been cases where I started with a program containing several thousand lines of code, and the operation reduced it to a "reproducer" with less than a hundred lines. This reproducer will often look pointless, do nothing that is of interest to the program users, and is usually of no use to anyone other than to display the compiler bug. So, you should find it easy to obtain approval from your employer to submit the reproducer.

[Steven_L_Intel1]

Error 6405 about variable I happens if you have a USE of two different modules each of which declares something named I (probably not the best choice for something in a module!) But your other errors suggest a misunderstanding of Fortran program structure so the later error may just be a side-effect.

[Lorri_M_Intel]

I would look at :

<file name>.f90(1234):

  that is, line 1234 in your <filename>.f90 file.  This is the line just before the one giving the "contains" fail.

Is there anything interesting about that line, or any previous line in that vicinity?

                     --Lorri

[Laura_S_3]

There is nothing at all weird anywhere near the "contains" statement.

I commented out the the includes for two of the biggest routines (including the one that was dying at the "contains"), and got an internal compiler error.

<file name>.f90(8): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.

So, there is definitely a compiler bug, although it still could be being triggered by some subtle non-standard usage. This is going to be a tedious task refactoring until things compile again. Fortunately, this module needs a refactor anyhow.

[Laura_S_3]

Found an isolating (but not small yet) reproducer on some of the issues. The following code triggers the compiler error, which pretty much isolates the issue to the module_switchconnectivity (or one of its dependencies). I'm trying to further refine the location now.

module Sample

CONTAINS

   subroutine Sample_Sub
      use module_switchconnectivity
   endsubroutine Sample_Sub

end module Sample

[Steven_L_Intel1]

This may depend on the content of module switch_connectivity. 

[Laura_S_3]

Given the reproducer, yes, it pretty much isolates it to that module (or dependencies thereof). :-) Fortunately, that module is constructed with "includes" so it is easy to comment out pieces. Unfortunately, their isn't a single smoking gun. It "feels" like it is size-related - comment out a couple of semi-random subroutines and it no longer produces a bad module. Splitting out these subroutines into a module of their own also solves the problem. It is still possible it is some interaction of subroutines however. (I'm going to try bisect the problem again today to see if I missed a pattern yesterday.)

I should probably mention this compiles (and runs) fine under GFortran, which is usually more picky and less modern-feature-complete than Intel Fortran.

[Steven_L_Intel1]

Does it build with version 17? That would tell me if it is an issue we need to pursue.

[Laura_S_3]

I don't see Intel 17 on any of the systems I have access to yet, but I'm sure it will show up sometime soon on the newer systems. However, if I resolved this issue before then, it is unlikely I will have time to come back to it later, unfortunately.

[jimdempseyatthecove]

>>Fortunately, that module is constructed with "includes" so it is easy to comment out pieces.

You really should move away from INCLUDES as this can cause dependency issues.

What happens when you replace the includes in module_switchconnectivity with the contents of the include file (repeat if necessary), then perform the build, and build twice? If the build succeeds, then the dependency checker might be observing an ABA situation.

If the above works, then go back to your original method, and change the INCLUDE to a properly constructed USE .... with new modules.

Jim Dempsey

[Laura_S_3]

Why would includes cause dependency issues? Wouldn't the exact same issues be present if the code were in-line? The includes are just to keep the module file sizes more manageable. Everything (in the non-legacy code, anyhow) is in modules.

[Laura_S_3]

So, I got it to compile on two different systems, but I don't think the underlying issue is truly resolved. (Also, it doesn't run correctly yet, but that might be a link problem.)

To get it to compile, I took some deadwood subroutines out of one module to fix the "bad module" issue. Then I had a series of problems where it would flag syntactically correct code as incorrect. In each of these cases, removing "use" statements from the subroutine when they were already in the module declaration solved the problem. Weird. I suspect one of the lower level modules is not being compiled properly and is causing erratic behavior downstream.

[mecej4]

I wonder if you have an incorrect build order. Do you use Make/Cmake, etc.? How do you build?

Some of the problems that you describe are symptoms cause by the use of stale .mod files.

[Laura_S_3]

I'm using make, and compiling in clean directories. With the clean directory, incorrect build order and circular dependencies tend to become very obvious since the .mod file isn't there. So, no, I don't think it has anything to do with compilation order.

[jimdempseyatthecove]

In your #1 post, anything after the first error should not be considered for examination. Once the first error occurred, and if it were a statement ordering issue, then errors that follow are (may be) meaningless.

Because you are using INCLUDES (or are you using #include and failing to mention this?), it is possible that the (or one of the) include files is terminated with a statement without a line termination?

Jim Dempsey

[Laura_S_3]

I am using some #includes.

Keep in mind, this program compiles and runs correctly with several previous versions of Intel Fortran as well as GFortran. Also, keep in mind that simply removing a few redundant "use" clauses eliminates most of the "errors" reported by the compiler. While I have little doubt that there is some unusual Fortran usage triggering the compiler bug (or it would have been found long ago), I am pretty sure it isn't something basic. I've made basic mistakes often enough over the years that I'm pretty good at detecting them when I make them again. :-)

[Steven_L_Intel1]

We would very much appreciate it if you could put together a source (or sources) that show the error that you are allowed to give us. This will help us help you, as well as other users. Thanks.