Conditional Breakpoint within Plato

Since I'm stuck with a bug, I tried to set a conditional breakpoint within Plato. The corresponding line, however, is greyed out, so that it can't be selected. Compiler settings are Debug in X64 environment. Maybe someone can give me a hint, concerning presettings so that I can use the conditional breakpoint feature. Please note, that I have no experience with command line use of SDBG, but use the Plato environment. Kind regards Theo

P.S. Regular breakpoints can be set/toggled offline using Plato, for setting conditional breakpoints in Plato, debugging needs to be active. I.e. move the cursor to the desired position, right click and select ´run to cursor´ (or simply Ctrl+F10). Then right click and ´Set conditional breakpoint` can be selected (or with Shift+F2).

How big is the program that you are debugging? Is it feasible to post the source files (and data files, if needed), along with instructions to reproduce the bug?

Quoted from mecej4 How big is the program that you are debugging? Is it feasible to post the source files (and data files, if needed), along with instructions to reproduce the bug?

Thank you for replying mecej4! It's a bigger program - too long for posting it. I will prepare it and post it at a suitable place with corresponding input files and information concerning the problem. I will prepare it and post the information as soon it is available. Kind regards Theo

The stable running version is Coupled-V2.FOR with input files FT05.DAT, MXuc.DAT and MXoc.DAT. The correct output files are FT06-ref.DAT, FT30-ref.DAT and FT31-ref.DAT. Files required for output are: FT06.DAT, FT23.DAT, FT30.DAT and FT31.DAT. I have stored all files here: https://www.magentacloud.de/share/pnjh5vew8r. In version Coupled-V3.FOR an additional output file is required: FT24.DAT. This version contains the bug I try to eliminate. Differences between version V2 and V3 are additional printouts in V3 from subroutine FCC at lines 1214-1215, 1228-1229 and 1244-1245 stored in YR(i) and YS(i). These printouts to FT24.DAT are performed in subroutines OUTC and DRUCK. YR(i) and YS(i) are passed through subroutine calls of FCCx after failing to do so by named COMMON statements in FCC, OUTC and DRUCK containing the arrays YR(I) and YS(I). That deliverd an invalid floating point operation around line 1995 (Computation of test value Delt) with DELT=1.#QNAN in line IF(DELT-PRMT(4))19,19,17 after DO 16. The transfer of the arrays YR(i) and YS(i) – similar to the ones of Y(i) and DERY(i) - however causes an access violation in Coupled-V3.FOR at line 1245 YS(J+I3) = X2. I still fail to identify the problem, since the values for J+I3 seen during debugging are within the limits of 120. What irritates me: When modifying the program in Plato with copy and paste within the program, during paste I get the pop-up window containing the text: „If the paste contains UNICODE characters, use the ´Advanced Save options´ to select the desired code page for this file“. Up to now I have ignored that and guess it’s not related to the bug in the program.

I'm sorry to point out that your 'stable running version' V2 itself has some errors, which apparently you have not noticed. I think it is best to fix the errors in Coupled-V2.FOR before using its results to validate the V3 version.

Apart from the Unicode characters that you noticed, the source files have some Tab characters in them, which can be a source of trouble because different compilers can give them different interpretations.

My suggestion is for you to compile the V2 program with the /undef option, link and run the EXE. When an error occurs, such as an incorrect subscript or use of an undefined variable, examine and correct the source file and repeat.

Here are a couple of errors that I noticed. Line 1654 of Coupled-V2.FOR contains:

      IF (.NOT.(IR.GT.1.AND.R2N(IR).GE.R2N(IR-1))) GOTO 113

When this line is first executed, IR has the value 1, and consequently it is illegal to reference R2N(IR-1), i.e., with subscript value 0, because the lower bound of the array is 1.

Some elements of arrays ZW and GMA are used without having been previously initialised. If you want them to be preset to zero, you have to take appropriate action, such as using the compiler option /zero, or adding code or DATA statements to do the initialisation.

Thanks for your hints mecej4! - indeed many tabs are used and also obviously unicode characters - which I wouldn't have expected to cause problems. So I will try to eliminate these plus the missing initializations. I tried to use the compiler /zero option before in other programs, but that even deteriorated the situation, so that I returned to manual initialization. Good that you noticed the illegal reference R2N(IR-1). I hope to find the remaining errors using the \undef compiler options as you suggested. I'm curious if that changes the results. Best regards Theo

Besides /undef add also /check

The /undef option implies /check, please see https://silverfrost.com/ftn95-help/devel/checking_for_undefined_variables_undef.aspx .

Theo:

Both the source files that you provided contain ENTRY statements in subprograms, but the usages do not obey this language rule:

'If the ENTRY statement is in a subroutine subprogram, an additional subroutine is defined by that subprogram. The name of the subroutine is entry-name. The dummy arguments of the subroutine are those specified in the ENTRY statement.'

When the ENTRY is followed by an argument list, the arguments of other ENTRY statements and those of the containing subprogram are not passed and are not available.

Local variables in subprograms are not saved unless you specify the SAVE attribute.

Mecej4 gives good advice to use /undef

I compiled using : FTN95 coupled-V2.FOR /-implicit_none /undef /link SDBG coupled-V2.exe

This showed in subroutine READAT

      DO 161 K=1,IZ
      Z=ZW(INDE(K),INDE(J))*(EE(INDE(K))-EE(INDE(J)))/(EI(K)-EI(J))
      IF (INDE(K).EQ.INDE(J)) Z=ZW(INDE(K),INDE(J)+1)*
     & (EE(INDE(K))-EE(INDE(J)+1))/(EI(K)-EI(J))
      IF (KOKO.LE.0) Z=0.D0
161   DMA(K+I1,J+I1,IR)=Z

needed to be changed to

       DO 161 K=1,IZ
        IF (INDE(K).EQ.INDE(J)) then    !  patch for
         Z = ZW(INDE(K),INDE(J)+1)
     &     *  (EE(INDE(K))-EE(INDE(J)+1))/(EI(K)-EI(J))
        ELSE
         Z = ZW(INDE(K),INDE(J))
     &     *  (EE(INDE(K))-EE(INDE(J)))/(EI(K)-EI(J))
        END IF
        IF (KOKO.LE.0) Z=0.D0
161     DMA(K+I1,J+I1,IR)=Z

The order of the IF test is not guaranteed in the standard.

Further, it appears that arrays CMA and GMA are not (sufficiently) initialised. I presume there are further problems. Perhaps you need a routine INIT to zero all global variables. I am not sure about the local variables. Although /ZERO may be essential, it is not a good option for modern Fortran.

I expect /SAVE and /ZERO will also be necessary for this program to work anything like it did with the previous compiler and operating system on which it was developed.

This is an interesting example of what to do as a minimal fix to get the program to work.

For example: in Subroutine TVR, which has local variables T(10000), NSTT and the DO index NP. These are referenced using ENTRY TVR1. You would definately need SAVE for this to work.

I don't know the history of this program development, but it will struggle to work with the rules of 'modern Fortran F90+'. You definately need to understand the rules for ENTRY with the original compiler.

So that your work scope doesn't explode, you should think carefully what are minimal changes required to approach the Fortran environment in which the program was developed. Make sure you keep a copy of the original version so that you can start again with the updates as you better understand what this means.

You need to be careful, to confirm the program works, even after it works for the limited cases you have provided. This program is not standard FORTRAN.

Thank you for all the hints and advices! I have modified Coupled-V2.FOR into Coupled-V2d1.FOR (also stored here: https://www.magentacloud.de/share/pnjh5vew8r), following the advices of mecej4, i.e. removed all tabs and assured it's a plain ASCII-File now. I added various intitializations for the arrays mentioned (ZW, GMA and others) and removed the error (R2N(0)). Compiling with /DEBUG runs fine (as before), but using CHECKMATE ends up with 'Reference to undefined variable, array element or function result (/UNDEF) at address 4298c0' Within file Coupled-V2d1.exe in FCC in line 1210, at address 5bd4 in DHPCGO in line 1999, at address fe9 in MAIN@ in line 763, at address 14337 Array DJK(J,K) in FCCR is labelled as undefined vor J=1 and K=2 during the 8th call, although beeing intialized in subroutine IPOWER and INTPO. So this is still not, what I'm looking for (and keep on searching..). @John: This Module was developed in the 80th (FT77) and I revoked it to check some current calculations. I took over your suggestion for the IF statement in READAT. Thanks for the hints concerning TVR - this module is not used with the current input parameters - but I keep that in mind, when I need to use it. Yep, copies of the originals are definitly kept! So I keep following the advice of mecej4 to eliminate the errors of this version, i.e. it should work without problems before returning to version 3. Have a nice weekend 8) ! Theo

File Coupled-V2d2.FOR contains slight modifications, however, with the same result using checkmate: Reference to undefined variable, array element or function result (/UNDEF) at address 42a740 Within file Coupled-V2d2.exe in FCC in line 1215, at address 69fc in DHPCGO in line 2042, at address fed in MAIN@ in line 765, at address 1433e What puzzles me: Array DJK(J,K) is computed correctly (as array G(K,J) in IPOWER) 8 times. Upon RETURN to FCCR after call 8 all elements of array G(K,J) are labelled as undefined in FCCR and cause the message above. I guess I will develop a workaround for what was originally planned in version 3, since I can't find a solution at this point. Thanks again for your helpful input. Kind regards Theo

I can explain the 'puzzle', but that may not help you much. The big issue, as I see it, is as follows.

The code contains several violations of the Fortran standard, as we have discussed before. Pages 94-97 of the 1993 IBM VS Fortran (Fortran 77) manual, which can be seen at http://publibfp.boulder.ibm.com/epubs/pdf/afbr1001.pdf , support this claim with respect to ENTRY. What a compiler does when given nonconforming code is not specified by the standard, so running the code can do anything today, and it may do something different tomorrow. Furthermore, ENTRY, even when used in a Fortran-77 conforming way, is now obsolescent.

In such a situation, it is futile to try to infer, merely by looking at the program source, what the program should do. Nor is expertise in Fortran sufficient, because it is only an expert in the subject matter (particle physics?) who can tell what the calculation is supposed to be doing.

Here is the explanation for the array DJK becoming undefined. DJK is a local array in subroutine FCC (which has ENTRY FCCR in it). Unless DJK is declared with the SAVE attribute or a /SAVE option has been specified to the compiler, the values in DJK (and all such local automatic variables) are undefined when the containing subroutine is entered through the subroutine name or an ENTRY name. After this, the code in the subprogram may cause DJK to become defined, but this is in effect only within the subprogram. Here is the wording from the Fortran 2003 standard:

16.5.6 Events that cause variables to become undefined

*(3) When execution of an instance of a subprogram completes, (a) its unsaved local variables become undefined, *

If I was going to attempt to get this program going with FTN95, my first task would be to use /implicit_none (and probably /save /zero as an interum measure to minimise problems)

In the routines that have ENTRY, you need to: identify all local variables and determine if they need the SAVE status identify all arguments and ensure they are not referenced via an alternate entry pathway. (I think the SAVE atrtribute was included in F77 so this save/dynamic goes back a long way.)

As for the issue of /ZERO, even McCrakken Fortran IV that I learnt in 1973, didn't allow assumed zero initialised arrays. For global arrays you need an initialisation routine. For assumed zero for local arrays in subroutines, I don't know how to approach that. I presume the original compiler provided all local arrays as SAVE attribute ands initialised to zero. You can reproduce that with a lot of data statements or easily use the following modified definition: INTEGER :: NR = 0

My recollection of McCrakken is the need for /ZERO is just wrong as I was taught to always initialise variables. Also, DATA statements implied SAVE, which has been my approach.

So particle physics! When I did computer science and engineering, those physics students had a bad reputation for Fortran skills. I'm sure it wasn't true but examples like this do not help.

mecej4, thanks for your patience and persistence in explaining the problems related to the ENTRYs plus providing the link to the IBM VS Fortran (Fortran 77) manual!

Indeed you are right in stating the necessity to obey the rules/ behaviour of the current compiler being used. I.e. the fact, that these subroutines, including arrays with variable dimensions worked (despite of various jumps from ENTRYs to other subroutines and back) without losing their array elements on a specfic IBM mainfraime in the 80s, doesn't mean this also works for other/current compilers. Obviously the SAVE attribute also was in the scope of FT77, however, we/ I never used it, since both UNIVAC and IBM mainframes worked fine without it.

A quick try to provide the /SAVE parameter didn't work, i.e. delivered the same error messages. So I modified the variable arrays in FCC to fixed ones (except for Y and DERY) and specified the SAVE attribute for them. That led to further undefined and out of array bounds messages related to the subroutines IPOWER and INTPO, which could also be fixed by providing intial values and SAVE attributes.

So finally I succeeded in compiling Coupled-V2d3.FOR using /CHECKMATE without further error messages. Although the content of the output files FT30.DAT and FT31.DAT differ significantly from those obtained earlier, the final result of the physical spectra calculated in the following step (QED, atomic physics) are correct again.

Thanks a lot for your help, also to John Best regards Theo

Two further comments.

1. In subroutine TVR, you have an array of 4-byte strings declared as INTEGER. This was unavoidable in Fortran-66, but in Fortran-77 CHARACTER became available.

2. When reworking old mainframe Fortran code such as this, it is often helpful to build and run with different compilers and compare the output files. In your program, many list-directed WRITE statements are used, i.e., WRITE(nn, *). This is convenient when developing a program because it allows you to avoid constructing format strings, but it is also an obstacle to comparing the results from different compilers, because each compiler is allowed considerable flexibility in how to format the output.

It is better to replace the FMT=* in the WRITE statements with suitable format statement numbers and furnish those FORMAT statements.