Wrong indices of an array of derived type in the debugger

I am still trying to make a simple program to demonstrate this, but we have being having this problem for a long time, and basically we get what you see below (left part is the start, and right part is the end)

Also wanted to add that we are allocating various variables of different sizes (eg. 0:41, 0:500), but after allocation, if we hover over the variable, we can see that the range is always -2139062144:16843008

Based on your recent posts concerning /UNDEF and /INHIBIT_CHECK=10, I have constructed a short program to demonstrate a scenario where you may obtain such results.

The first output number, -2139062144, is Z'80808080', which is the bit pattern used to represent undefined variables when /undef is specified. If such an undefined value is passed as an argument to a subroutine whose code was not compiled with /undef, results such as those that you observed can be produced.

Take the following program units and put them into separate files. Compile the main program with /undef and the subroutine without /undef, link and run.

The main program:

program StamKBug
implicit none
integer idx
call sub(idx)
end program

The subroutine:

subroutine sub(idx)
integer idx,i
do i=1,10
   write(*,'(1x,i2,I12,2x,Z8)')i,idx,idx
   idx=idx+1
end do
return
end

Quoted from StamK Also wanted to add that we are allocating various variables of different sizes (eg. 0:41, 0:500), but after allocation, if we hover over the variable, we can see that the range is always -2139062144:16843008

Again, this is only a single symptom of multiple errors in your program. The lower bound is Z'80808080', which stands for 'undefined', if /undef was used when compiling. The upper bound is Z'01010100', which again indicates some sort of error.

Don't expect any resolution of the problems in your code through forum posts until you can supply a more complete description, a reproducer, or (if tolerable) the complete source code and build instructions.

When a program being investigated is very large, it is not productive to use /undef at the outset. Likewise, when there are program bugs present it is often useless to run the program in a symbolic debugger. As you have demonstrated, what the debugger shows you can be of limited use and may be quite confusing.

I find it more useful to use these steps when investigating large character mode programs:

1. Build and run the program without /check or /undef. Fix bugs as far as you can in order to get the program run to completion. The results may be incorrect, but at least the program runs.

2. Repeat with /check. Fix argument mismatches, incorrect file access and I/O statements, array bounds errors. Evaluate the results again.

3. Repeat with /undef. Many programs may work correctly even when undefined variables are present, so be cautious not to spend too much time with /undef, especially in the context of old programs from the mainframe era.

4. Profile the program and note which sections of code were not exercised. These sections may still contain bugs, and those bugs may only surface when different inputs are used several years later, so documenting the code and development of verification runs are important.

Many thanks for that.

/CHECK gives exactly the same problems. The program works fine (most of the time), but we do get the occasional, non-easily repeatable crash, and so we are trying to see if we can use /undef to find something. We used to use it a lot, but since the end of last year we basically gave up on it (because of the issues raised, some of which have just been fixed by Paul and Robert).

Now however we are a bit stuck and we need to get back to it. Apart from the indices, there is another issue, but I cannot reproduce it in a simple example unless I give the whole program to Paul, which I think I may do.

This is very strange.

I am now using the latest slink v1.48, and I don't get (in the large program) those strange indices any more, but now they are (0:0), even though I have done ALLOCATE(SERS(0:NS)) where NS=50.

Very strange...

Since you show no supporting observations, I have to conclude: 'Strange to you, unknown to the rest of us'.

I have SLINK 1.47, which is the version that was released with FTN95 V 8.5. I do not have SLINK 1.48, and I do not know how to obtain it. If you still have an older version of SLINK than 1.48, please try to reproduce your findings with it.

I do not see any strange things with the 64-bit FTN95 V8.51/SLINK64 2.10 either.

Here is counter evidence:

program strange
integer, parameter :: NS = 50
integer, allocatable :: sers(:)
!
allocate(sers(0:NS))
print *,NS,allocated(sers)
end program

I see in SDBG64 when the current line is Line-6:

SERS = INTEGER*4 (0:50)

As I said, I cannot reproduce it in a simple example, so of course what you did will not show it. 😄

Robert: I sent you yesterday an email with the files to download from wetransfer. Thanks