forums.silverfrost.com

KL · Joined: 16 Nov 2009 Posts: 155

This is a very small problem: the compiler reports the error:

PaulLaidler · Posted: Sun Dec 06, 2009 4:51 pm Post subject:

The compilation fails because the line declaring n has been commented out.
If you can run the program then you must be accessing another copy of the executable.

KL · Joined: 16 Nov 2009 Posts: 155

Paul,

as you can see from my batch file, I delete the executable before compiling and linking. There is no other executable somewhere. Indeed, if I link directly, the program stops.

Best regards,

Klaus

PaulLaidler · Posted: Mon Dec 07, 2009 9:14 am Post subject:

I do not understand how this is happening but I am confident that the executable will not be created if the main compilation fails. It may just be possible to have a subroutine fail to compile and for the link to go ahead with a missing subroutine. Then the executable could run until an attempt is made to access the missing routine.

However, it is more likely that something odd is happening, such as another copy of the executable existing somewhere else on the PATH.

Anyway the solution is to uncomment the line that declares the variable.

Paul

KL · Joined: 16 Nov 2009 Posts: 155

Paul,

the solution is clear, but please try it yourself. Just put the program, the link file and the run file in a directory. Definitively, on my PC there is no other executable with the strange name "Problem_Error_Stop.exe". If you wish, I can send you the files directly.

Klaus

sparge · Joined: 11 Apr 2005 Posts: 371

Klaus,

I tried this and I cannot reproduce the problem. I created the source file, the batch file and a file called simply linklist. No exe is produced or run. When the batch file gets to the point of invoking the linker, it prompts me:

^CTerminate batch file? (Y/N)

after which point, comp.lis contains:

[FTN95/Win32 Ver. 5.10.0 Copyright (c) Silverfrost Ltd 1993-2007]
Licensed to: Andy Spragg
Organisation: RHM Technology Limited

0009) n = 3
*** N must appear in a type declaration because IMPLICIT NONE has been used
1 ERROR [<PROBLEM_ERROR_STOP> FTN95/Win32 v5.10.0]
*** Compilation failed

and link.lis contains:

$ *** Could not open: linklist
[SLINK/Win32 v1.42 Copyright (c) Silverfrost Ltd. 1995-2007]
*** No object files loaded

the latter of which which makes me wonder if I have done something silly with my files (forgive me, but command line compiling and linking is a distant memory for me).

Andy

KL · Joined: 16 Nov 2009 Posts: 155

Andy, this never happened to me, except for version 5.40.

Best regards,

Klaus

KL · Joined: 16 Nov 2009 Posts: 155

Paul,

I think there are 3 evidences supporting my findings:

1. There is no other executable "Problem_Error_Stop.exe" on my PC. I have checked this carefully.
2. The link step is documented; the corresponding date and time are correct and prove that the new executable has been created with the new run.
3. The strongest argument is the following: I have modified the "program" simply by setting n=5. Any old executable would not be able to know this change and would print out the old value n=3. However the new run succeeds, the linkfile and the new executable have the correct time and the (new) result n=5 is printed out.

Please note that in this example, the problem looks ridiculous. However, when you work with several hundreds of programs and you need to recompile all of them, then such an error would be difficult to be detected.

Best regards,

Klaus

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

I tried the example, using the 3 files
problem_error_stop.f95
linklist
problem.bat

With both Ver 5.30.0 and Ver 5.40.0, it produced a .obj file then a .exe file and ran through sdbg
The program appeared to run successfully.

There is a problem that the .obj file was not deleted when the error was identified.

PaulLaidler · Posted: Tue Dec 08, 2009 8:49 am Post subject:

This "problem" has been the default from the beginning.
There is a command line option /delete_obj_on_error that you can use. You can also configure FTN95 so that this is always on.

Plato and VS IDEs provide this option for you automatically.

KL · Joined: 16 Nov 2009 Posts: 155

Paul,

thank you very much for your comments.

I still believe that there is somewhere a little inaccuracy (of course not a problem):

First of all, this type of error has never happened before although I have never changed the configuration.

Secondly, I have changed the configuration as you suggested but the "problem" remains. But as already reported, if I change the bat file to

KL · Joined: 16 Nov 2009 Posts: 155

Are there any news or am I making somewhere a big mistake?

Best regards,

Klaus

PaulLaidler · Posted: Mon Dec 14, 2009 5:52 pm Post subject:

I have now checked this out and I need to correct what I have written above.

There are two kinds of error, fatal and non-fatal. If the compiler encounters one or more fatal errors then the object file is deleted when /delete_obj_on_error is used. Also delete_obj_on_error is the default state in the compiler. So this is always switched on unless you switch it off on the command line.

The error here is not fatal and the code is otherwise correct so the object file is created and is fully functional.

So the question is not "why does this work now" but "why did it not work before". The first possibility is that, on the previous occasion, the error was combined with other errors that were fatal.

KL · Joined: 16 Nov 2009 Posts: 155

Paul, thank you for the explanation.

Have you checked why the link step stops if I do not use slink, i.e.

PaulLaidler · Posted: Mon Dec 14, 2009 8:49 pm Post subject:

I have now checked this behaviour and the internal link does not proceed when there are non-fatal errors. Unless I am missing something, there is clearly an inconsistency here.