No Stop on Error

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

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

Nevertheless, the program is executed. The program was run with FTN95 version 5.40 and the following batch file:

del comp.lis
del *.obj
del *.exe

ftn95 Problem_Error_Stop.f95  /Checkmate /underflow  >> comp.lis

slink LinkList > link.lis
  
sdbg  Problem_Error_Stop.exe

I have never experienced this error in previous versions. The test program is:

  Winapp

  Program Problem_Error_Stop

 
    Implicit None
!   Integer                :: n

    n = 3

    Write (*,*)   ' n = ', n

  End Program Problem_Error_Stop

The linkfile is:

LOAD  Problem_Error_Stop
file  Problem_Error_Stop.exe

I do not think that this behaviour is intended since the batch file stops if slink is not used.

Best regards,

Klaus Lassmann

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.

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

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

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

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

9. 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

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

Best regards,

Klaus

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

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.

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.

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

del comp.lis
del *.obj
del *.exe
ftn95 Problem_Error_Stop.f95  /Checkmate /underflow /link  >> comp.lis
sdbg  Problem_Error_Stop.exe

i.e. without the slink step and the error is detected. Could it be possible that something was changed in slink?

Even if I use the option /delete_obj_on_error directly

del comp.lis
del *.obj
del *.exe
ftn95 Problem_Error_Stop.f95  /Checkmate /delete_obj_on_error >> comp.lis
slink LinkList > link.lis
sdbg  Problem_Error_Stop.exe

the problem remains.

Best regards,

Klaus

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

Best regards,

Klaus

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.

Paul, thank you for the explanation.

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

del comp.lis 
del *.obj 
del *.exe 
ftn95 Problem_Error_Stop.f95  /Checkmate /underflow /link  >> comp.lis 
sdbg  Problem_Error_Stop.exe 

It seems that both ways of linking are different: one continues to link and run, the other stops.

Best regards,

Klaus

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.

Paul,

thank you very much. As you mentioned, this 'problem' does not concern fatal errors. I am sure that your team will have a look to this issue and find a consistent solution.

Merry Christmas and a Happy (and successful) New Year to all of you.

Klaus

I have fixed this for the next release so that FTN95 behaves consistently in this situation.

Paul,

thank you very much. I can wait for the correction.

Klaus