Incorrect/missing line numbers in traceback after abort

The following test program contains an error in the declaration of the size of an array dummy argument. When the program is compiled and run with /debug /check, the line numbers in the traceback are not consistently reported.

First, the source:

      PROGRAM DRIVR
      implicit none
      integer, parameter :: NCL = 101
      REAL T(NCL)
      call stcomp (t)
      
      CONTAINS
      SUBROUTINE STCOMP(V)
      IMPLICIT NONE
      REAL V(501)            ! bug here, should have been (101) or (NCL)
      INTEGER :: I
      do i = 1, NCL
         V(i) = 0.02*(i - 1)
      end do
      return 
      end subroutine stcomp

      end program drivr

When compiled and run at the command line, FTN95 8.30 (32-bit) gives

Runtime error from program:s:\nls\difcor\tst1.exe
Run-time Error
Attempt to call a routine with argument number one containing too few array elements
 DRIVR~STCOMP -  in file tst1.f at line 7 [+004d]
 main -  in file tst1.f at line 5 [+0047]

This is odd since Line-7 contains 'CONTAINS' and is not even an executable statement.

If we now add the option /64, the traceback is

Within file tst1.EXE
in DRIVR~STCOMP at address f8
in DRIVR in line 5, at address 4e

Note that the first item shows only an address and no line number.

When the same EXEs are run in SDBG/SDBG64, the tracebacks are different.

SDBG-32 shows only one line number in the traceback, namely, Line-5.

SDBG-64 shows the full traceback with correct line numbers.

Thank you for the feedback. I have made a note of this error.

Mecej4,

Out of interest, where does the error occur? When the subroutine is called, at the entry point of the subroutine, or where the size of the array is declared? If the latter, in the calling program or in the subroutine?

Is a blank line a line at all in this context? If not, then line 7 is the Subroutine start (/64) whereas line 5 is the Subroutine call (/32). So maybe there are different answers to my first question above.

I think that with the message 'Attempt to call a routine with argument number one containing too few array elements' I would find the programmer error more easily if the name of the subroutine were given rather than a line number, especially if the name included the container, which needn't be the main program in the general case)

(Noted the split infinitive, by the way. Can I have pedant of the day award please?)

Eddie

The error occurs in http://www.netlib.org/a/difcor . This is a Fortran-4 source code written for a CDC mainframe, even though it was published in the 1980-s. In addition to the error about the dummy array size, which I encapsulated in the test code, the DIFCOR program contains usage of some uninitialized variables, expects 48-bit precision for REAL, and declares the names of files as arguments in the PROGRAM statement. FTN95 is very helpful in getting such old codes working on a PC.

Line-numbers: think of each line as a card image, and imagine that every card, blank or not in cols. 1-72, contains a seq.no. in cols. 73-80. The line number is what would have been the seq.no. on the corresponding card. One hopes that every text editor and source code pane in an IDE or debugger would display the same line number for a given file. The various tools in a single compiler package ought to share one definition of line number.

Tracebacks: In Fortran-4, all subprograms had implicit interfaces. Subprograms were compiled separately. Calls from other subprograms had to be compatible with the implicit interface of the callee. An incompatible argument list in a CALL (or function reference) is an error in the CALL statement (or function reference); but, with separate compilation, the subprogram has be entered before the arguments can be checked for compatibility. Ideally, the runtime should present the line numbers of the back-trace, starting with the line containing the declaration of the incompatible dummy argument and that argument should be named. If that is too hard to do, one could settle for the line number of first executable statement of the subprogram, or just the name of the subprogram, and the ordinal number of the argument.

[For Eddie]

Split infinitives: They may provide welcome distraction from splitting hairs. As H.W. Fowler said, 'The split infinitive is an ugly thing ... but it is one among several hundred ugly things' ( www.bartleby.com/116/503.html ). The error message reminds me of 'For sale, piano, by a lady with wooden legs'.

I get a 404 for the web reference, and when I run your test program it runs for me without error when neither debug nor check is specified. When I use those two additional options in I get the error report presented in a Windows version of the Silverfrost Debugger, with the highlighted offending line better in the 32 bit version at line 5 (no line numbers given with that version), or on the DO loop line (line 12, and not your line 7) in the 64 bit version, which does have line numbers. The Windows debugger pops up even though I compiled at the command line. Odd. The variables window is more helpful in the /64 version than the /32, but the highlight better in /32. In both cases finding the bug would be easy, even ignoring your helpful comment! So agreed, they are reported inconsistently.

Yes, I remember giving names for files in the PROGRAM statement - some other compilers didn't need a program statement at all.

I'm surprised that a CDC expected 48 bit for a REAL, as the CDCs I used all used one 60-bit word. (6400, 6500, 6600 and 7600 machines used). The Elliot and ICL computers I used back then had 2 x 24-bit words for a REAL, but this wasn't what I expected from anything US-made.So I researched earlier CDC computer systems and they had 24 bit or 48 bit words, thus using 48 bit single precision REALs like contemporary UK computers.

The late Professor Zienkiewicz (noted for his work on the Finite Element method and related books and papers) once told me in conversation that as most US Universities used computers with 32-bit REAL precision, some of the algorithms he published didn't work for them, and he was subjected to a barrage of complaints that his published results (obtained with higher precision on ICL 1900 series machines) were not repeatable. Perhaps Zienkiewicz's correspondents couldn't afford CDC, and were cursed with some other brand, it not being a mistake (anecdotally) to specify IBM.

Although you have identified an error, it may not have mattered on the CDC architecture with their compiler. The same goes for uninitialised variables, as many compiler/computer combinations initialised everything to zero (see posts previously about what FTN95 does).

Your section headed 'Traceback' is useful, as I hadn't considered separate compilation. I suspect that having a CONTAINSed subroutine in a separate file would make this whole business harder to deal with.

When I was a card user, some compilers I used would gag at a completely blank card, and most of us eschewed them as they could violate some arbitrary limits as to how many cards one could submit, or worse in a commercial setting, could involve extra charges. One of the very positive things in modern Fortran is that it permits completely blank lines, not even needing to be blank comments.

As a matter of fact, provided that NCL does not exceed 101, it doesn't seem to matter with FTN95 without the additional switches, and since NCL has scope inside and outside the CONTAINSed subroutine, this could be an extraordinarily difficult bug to find if, say, NCL was set to greater than 501 when defined. (And I appreciate it is a demonstrator).

Regarding the uninitialised variables, it would have been a minor step in any revision of the Fortran standard to require all variables to be initialised to zero and the problem would then go away, because as far as I'm aware, they either aren't initialised at all, or they are initialised to zero, and they sure aren't initialised to anything else!

As far as reporting errors consistently between the two versions, I think it is more important that error reporting is done usefully than consistently (which I take to mean identically). I understand that /64 is a completely new and clean sweep as far as code generation etc is concerned, although that's only what I inferred. As such, it is more valuable to me than a simple extension of the 32 bit version, as it means I now have 2 separate compilers to run my code through. Other vendors' compilers are useless once one starts to use Clearwin+ ...

Mecej4, you should realise that it was tongue in cheek, and it is to be welcomed that you boldly continue to find bugs and inconsistencies!

Eddie

I have fixed the URLs.

The CDC 6000 X registers were 60 bits long, of which 48 bits were used for the mantissa, 11 for the biased exponent, plus a sign bit. See the page numbered 3-15 in the manual, http://bitsavers.trailing-edge.com/pdf/cdc/cyber/cyber_70/60100000AL_6000_Series_Computer_Systems_HW_Reference_Aug78.pdf .

The DIFCOR program uses 2^(-48) for, in effect, machine epsilon.

'I have fixed the URLs' - now I wish you hadn't. What a horrible coding style.

E

Eddie, I just noticed: your long post of today has been truncated in mid-sentence!

Thanks Mecej4, it should end:

Other vendors' compilers are useless when you get into Clearwin+.

Eddie

On the 1970's compilers I used, declaring 'REAL V(501)' would have not caused any problems, as V being an argument would have had memory allocation in the calling routine. As there was no array syntax, 501 was just an arbitrary dimension. CONTAINS was not available in the compilers I used, so NCL would have needed to be an argument or in COMMON, which defines the size used. This error only occurs when adopting F90 syntax.

Eddie, not sure I agree with your Zienkiewicz experience, as struggles with different REAL word sizes was a very common problem, perhaps except for those ignorant ones rusted onto IBM ! ( not us Salford users who were familiar with many reals )

I have looked at the program posted by mecej4 and there is indeed an incorrect traceback in this instance. Fortunately both SDBG and SDBG64 give the correct point of failure.