As a cross-check on my code, I do a compile on all the subroutines, and the main. I have a single compile with all the subroutines/functions INCLUDE'ed and the last INCLUDE is the main driver. I have four of these.

Two of these compile with no problems. Two will not. Indeed before V8.20.0, they ALL compiled successfully.

I removed all the functions/subroutines and only INCLUDE'ed the main routine, and that will not compile properly. With a RESOURCE at the end of the main, it yields an error in the resource file. Otherwise, it will end up in an endless loop. If I use the same automated process to compile the Main routine by itself (no additional INCLUDE's involved) the file compiles with no errors.

Also interesting is the .LIS file for the failed compile differs from the captured output; the capture shows the errors detected, but the LIS file does not.

I have not looked at this yet but I am wondering if there is a recursive use of INCLUDE. I don't recall if FTN95 protects against this.

In other words, one INCLUDEd file INCLUDEs another that has already been INCLUDEd in the chain. At a simple level you might have file1.ins INCLUDEs file2.ins where file2.ins INCLUDEs file1.ins, but it could be much less obvious than that.

I have now had a quick look at your project and there are at least two problems here.

1) There is a basic problem even if you work from a command line. FTN95 says there is more than one main program. I notice that you include a fixed format file in a free format program (something to think about here). This needs resolving before trying to build as a Plato project.

2) When using a Plato project, test_fort.for is not a "source" file in Plato terms. It is an "include" file and if you remove it from the "source" files then Plato automatically adds it to the list of "include" files. When problem (1) is resolved, Plato might now be OK. If not then you may need to disable the dependency checking.

I already have INCLUDES that have INCLUDES within them, but they do not cause the problem.

I also run everything from the command line; the Plato project was just a convenience.

The issue seems to be when this INCLUDE contains the FIRST executable statement. Put some other executable statement (an assign for example) before the INCLUDE within test_fort.for and the problem goes away.

I did just that, on a whim, and my two formerly un-compilable routines now can be compiled. My post to that effect on 22 Jan 2018 at 10:32 Mountain Standard Time may have been overlooked.

I have used this approach of include 'xxx.f95' to assemble all code in one group. I have done this for 2 reasons.
1) I have assumed that this grouping may offer better static checks of routine argument lists with /check
2) when using /timing, to group all routines that are being checked for relative run time; and exclude utility routines from the timing.

As with the above example, my file sim_ver1_tim.f95 consists only of multiple include statements, in the following order:
include module files
include program file
include subroutine files

I have not had the compiler problem reported above, so the problem is fairly specific.

You can also include files by tree name, although you need to take care with the location of included include files

For interest I would recommend this approach to using /timing, which can be very effective for identifying where most of the run time is being consumed. By careful exclusion of utility routines that are called millions/billions of times, you can get a good understanding of relative performance. Excluding utility routines means that the calling routines get allocated their times, so their performance is not lost.

Curiously mecej4's test code works correctly for me.
So currently I am looking at the case where the primary source file has no END for the main program and the END is supplied in the first level INCLUDE file. Also the first level INCLUDE must access a second level INCLUDE.
This fails for me appears to be a long standing bug.

The failure appears to occur when an INCLUDEd file is at the boundary between declarations and executable statements. This could be a fundamental limitation of FTN95 because of the way it deals with the complexities of Fortran 95 by making several passes through the user's code.

There appears to be no easy fix within FTN95 whilst the user could avoid this construction if FTN95 were to issue a suitable failure report. This may be the way we will go.

isn't the easy fix to create a temporary file concatenating all the files and includes into 0ne ? then compiling that complete temporary file ?

I mean automatically by the compiler as a pre-compile step, not relying on the user to do it._________________''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... "

Upon further investigation the reproducer provided by mecej4 does cause FTN95 to go into a loop and this has now been fixed for the next release of FTN95. Hopefully this will also fix the original issue.