The above examples seem to be working now for me.

Thanks.

I have isolated the other issue mentioned at the bottom of my original post in the following example.

If you put a break on the print *, x(1:10) line you will see the following variables in the Variables panel:

    ubound.0    *indeterminate*
[+] x                 [1000]
    x.0         *indeterminate*

Values in x array seem to be correct but ubound.0 and x.0 should not be shown.

This problem seems to be caused by presence of the internal subroutine "change".

Good luck with your investigations.

module test
contains
   subroutine modify(x)
      double precision, intent(inout) :: x(:)
      
      ! print first 10 elements
      print *, x(1:10)
      
      ! modify the elements
      call change
      
   contains
      subroutine change
         ! modify elements and return
         x = 0.0d0
      end subroutine change
      
   end subroutine modify

end module test

program anon

   use test, only: modify

   integer :: i
   double precision :: x(1000)

   x = (/(real(i), i=1,1000)/)
   call modify(x)
   
end program anon

A quick update.   I think the method Simply Fortran is using to create variables is, in this case,  incorrect.  I can get proper functionality with a small change to the debugger interface files.  I'll let you know when an update is available.

Simply Fortran's behavior in this situation (and I agree, it doesn't work as expected) should most likely be considered a GNU Debugger bug.  Simply Fortran does not interact with the GNU Debugger's conventional command line.  Instead, it uses the Machine Interface to communicate with the debugger.  To track local variables in an efficient manner, as suggested by the GDB documentation, Simply Fortran creates "variables" in the debugger.  When a Fortran array allocation occurs, the variable not only doesn't register as changed, but also it now appears to point to the wrong location in memory.  When frame changes occur, the variables are wiped out and new local variables are generated.  Therefore, after returning from the pass_array subroutine, new references to a and n are generated that point to the proper memory location.  The bug is that the debugger should know better that, on allocation statements, any variables affected should be updated to point to the proper memory location.

On the command line in GDB, it appears to work because you're probably using the "disp" command.  This command will evaluate the expression specified and print the result after each breakpoint (or step, whichever the user specifies).  Using "disp" would lead to an almost completely non-functional debugger interface because of the sheer quantity of information that would require processing on each step.

I'll look into fixing the issue.  It's an odd bug.

With the following code, the arrays a and n don't display properly in the Variables panel when a break is put on the print *, a line. However, they do display properly if you select the variables in the source code window and then point to them.

The Variables panel shows different wrong results for win32 and win64 targets (running on 64bit windows 8.1) and when using static vs. dynamic linking.

Strangely, once the print *, a has been stepped over, the values in the Variables panel change and become correct.

The array passed to pass_array always displays properly.

Edit: I have also found that it works correctly using gdb from a command window (outside Simply Fortran).

module mmm
contains
   subroutine pass_array(a)
      real, intent(in), dimension(:) :: a
      
      ! Check values (break here to look in debugger)
      print *, a
   end subroutine
end module

program main

   use mmm

   integer num
   integer, allocatable :: n(:)
   real, allocatable :: a(:)
   
   num = 10
   allocate(a(num), n(num))
   
   ! Populate arrays with 1 to num
   a = (/(real(i), i=1, num)/)
   n = (/(i, i=1, num)/)
   
   ! Check values (break here to look in debugger)
   print *, a
   print *, n

   call pass_array(a)
   
end program

In some of my production code, I also see other parts of the dope vector that is used by gfortran to represent the deferred arrays in the Variables panel - parts which should be hidden, e.g. for a real variable x I see x.ubound (seems to be a C struct variable) with a value of *Indeterminate*. However, I have not been able to reproduce a test example for this behaviour and cannot post my production code.