forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Odd compile problem
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Sun Jan 21, 2018 5:52 am    Post subject: Odd compile problem Reply with quote

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.

LIS file with the INCLUDE
Code:
Silverfrost FTN95/Win32 Ver 8.20.0  c-masterREPAIR_Routines.FOR  Sat Jan 20 21:33:48 2018

Compiler used    [C:\Program Files (x86)\Silverfrost\FTN95\FTN95.exe]
Salflibc path    [C:\Program Files (x86)\Silverfrost\FTN95\salflibc.dll]
Salflibc version [20.1.18.9]
Compiler options in effect:
    CFPP;DEFINT_KIND 3;FPP;IGNORE;IMPLICIT_NONE;INCLUDE;LIST;SAVE;
    WIDE_SOURCE;WINDOWS;

   0001   !!      include 'c-masterCFUNC_Functions.for'                                          AT 0
   0002   !!      include 'logplot\logplot_colors.for'                                           AT 0
   0003   !!      INCLUDE 'CBLOCK.FOR'                                                           AT 0
   0004   !!      INCLUDE 'cblock_init.FOR'                                                      AT 0
   0005   !!!#define INIT_ME 1                                                                   AT 0
   0006   !!        include 'cblock_BEDCODE_SPECIAL.for'                                         AT 0
   0007   !!        include 'cblock_BEDLIST_MAINT.for'                                           AT 0
   0008   !!        include 'cblock_BLOCK_DATA.for'                                              AT 0
   0009   !!        include 'cblock_BLOCK_DATA2.for'                                             AT 0
   0010   !!        include 'cblock_CLOGPLT.for'                                                 AT 0
   0011   !!        include 'cblock_IMPORT_HEADER_DEFINITIONS.for'                               AT 0
   0012   !!        include 'cblock_KML_LOGHEADER.for'                                           AT 0
   0013   !!        include 'cblock_POLYGON.for'                                                 AT 0
   0014   !!        include 'cblock_QUAD_SPECIAL.for'                                            AT 0
   0015   !!        include 'cblock_REFERENCE_SPECIAL.for'                                       AT 0
   0016   !!        include 'cblock_ROCKDEF_ROCKCOM.for'                                         AT 0
   0017   !!        include 'cblock_SCREEN_INS.for'                                              AT 0
   0018   !!        include 'cblock_SCRIPT_DATA.for'                                             AT 0
   0019   !!        include 'cblock_STATE_PLANE_ZONES.for'                                       AT 0
   0020   !!        include 'cblock_TRACT_SPECIAL.for'                                           AT 0
   0021   !!#undef INIT_ME                                                                       AT 0
   0022           include "catalog_repair.for"                                                   AT 0
*** Unsuccessful compilation of resource script
*** Compilation failed


Captured via a re-direct with the INCLUDE
[code:1:52b198a7d1][FTN95/Win32 Ver. 8.20.0 Copyright (c) Silverfrost Ltd 1993-2017]
Licensed to: William Horger
Organisation: CJD Software

NO ERRORS [<CREPAIR> FTN95 v8.20.0]
[Silverfrost SRC/WIN32 Ver 4.06 Copyright (c)
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Jan 22, 2018 8:51 am    Post subject: Reply with quote

Bill

It may be possible to work out what has gone wrong from your post but it is Monday morning at 7.50am.

Can you post the code for a short program that demonstrates the problem?
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Mon Jan 22, 2018 6:27 pm    Post subject: Reply with quote

I have an example that will cause the error, or put the compiler into an endless loop. It has done both to me in the last 30 minutes.

Here's the DropBox link:
https://www.dropbox.com/s/f3pxk4ftmidu775/ForumTesting.zip?dl=0
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Mon Jan 22, 2018 6:32 pm    Post subject: Reply with quote

If I move the INCLUDE statement down in the executable, then it works in my application. Being first up in the executable statements(?)...
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Jan 23, 2018 9:19 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Jan 23, 2018 10:42 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue Jan 23, 2018 1:47 pm    Post subject: Reply with quote

I get the same problem not using Plato, when compiling from the cmd.exe command prompt.
ftn95 forumtesting.f95
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Jan 23, 2018 2:41 pm    Post subject: Reply with quote

I think that we can create a simpler problem reproducer as follows.

1. Place the body of a small program in an include file, say 'body.inc', which itself contains an INCLUDE directive:
Code:
      PROGRAM TESTING
      character*12 bdts
      integer abcd
      include 'bdt.inc'
      abcd = 0
      stop
      end

2. Create a single line Fortran source file, 'main.f' with:
Code:
      include 'body.inc'

3. Place the following line in the file 'bdt.inc'
Code:
      bdts = 'Sun 01/21/20'

4. Attempt to compile the single-line source file, with or without /64, and observe the compiler going into a never-ending loop, repeating the complaint "*** More than one main program encountered".

I see the problem with version 8.1 and with the older 7.1 (32-bit only), building in a command window on Windows 10.

Curiously, the old FTN77 4.03, run on the same source file, sees no problems.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Tue Jan 23, 2018 3:37 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Jan 23, 2018 4:24 pm    Post subject: Reply with quote

I will make a note of this. It is possible that FTN95 can be tweaked so that it does not go into a loop in this context.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Wed Jan 24, 2018 4:32 am    Post subject: Reply with quote

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.

The batch file I use is:
Code:
now                             >ftn95.tce
del *.obj                      >>ftn95.tce
del *.mod                      >>ftn95.tce
SET TIMINGOPTS=/TMO /DLM ,

ftn95 sim_ver1_tim     /timing >>ftn95.tce
ftn95 sutil            /debug  >>ftn95.tce
ftn95 util             /debug  >>ftn95.tce
slink  main_tim.txt            >>ftn95.tce

type ftn95.tce
dir *.exe

phpa_tim test_xx.txt  >sim_tim.tce
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Feb 05, 2018 3:46 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Feb 06, 2018 11:35 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Feb 06, 2018 5:16 pm    Post subject: Reply with quote

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 (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Nov 02, 2018 3:45 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group