Spurious Error 15 in debugger

I have a problem that has started happening in the new v8.61 which did not happen in v8.50. In fact, this problem only happens in v8.61 DEBUG compiles (FTN95/windows/FULL_DEBUG/UNDEF/BINARY). The behavior is part of a large complex program not easy to put into a small test program.

I have a subroutine call with seven arguments: one INTENT(INOUT) and six INTENT(OUT) arguments. When running in the Silverfrost debugger, I get 'Error 15, Attempt to access undefined argument to routine' on the line that calls the subroutine.

1st attempt to fix is to pre-define the arguments - even though that shouldn't be necessary for INTENT(OUT) arguments - but this made no difference. Still get the error.

2nd attempt was to omit the declarations of intent in the subroutine. This was done out of desperation, but it did result in a change: Now Error 15 is thrown on the first executable line of the subroutine instead of on the call statement. In other words, now instead of dying before entering the sub, I can enter the subroutine and die immediately.

The problem is that I can't understand why I'm crashing on the first line. If the signature of my subroutine was: MySub(x1_inout, x2_out, x3_out, x4_out, x5_out, x6_out, x7_out)

then the first line of the subroutine is x5_out = .false.

so I'm getting an 'undefined argument' error when trying to assign a value to the argument!

Any advice or suggestions on what may be causing the problem and what can be done to fix it? This behavior makes it tempting to go back to the previous version of the compiler!

Thanks in advance.

I suggest that you try the version 8.66 of the compiler (see https://forums.silverfrost.com/Forum/Topic/3780 ).

You may also attempt to compile and run with just /debug (i.e., without /undef, etc).

If the problem remains, please provide a reproducer or at least show us the actual lines of code at issue. Your verbal descriptions are too abridged to enable a diagnosis of the causes of the error. The following test code, which I wrote based on your description, runs without error messages.

program debunk
implicit none
logical :: x1, x2, x3, x4, x5, x6, x7
!
x1 = .true.
call MySub(x1, x2, x3, x4, x5, x6, x7)
print *,'After call, x1 = ',x1
end program

subroutine MySub(a, b, c, d, e, f, g)
logical, intent(in out) :: a
logical, intent(out) :: b, c, d, e, f, g
!
e = .false.
if(a)then
   a = .false.
   b = .true.
endif
return
end subroutine

Thank you for the response. Downloading the latest compiler and debugger does not change the behavior.

I need to emphasize: There's nothing wrong with the code as it has been running for a long time - this is not new code I'm developing and testing. It was able to run and be debugged in v8.50. The issue is that when I upgraded to v8.61 I can no longer run my code in the debugger.

The code you provided is basically what I've got, though the data types aren't all logicals and there are some more layers. Below is a sketch of what it looks like. A lot of stuff is omitted, but I hope this is less abridged and will allow some diagnosis. My main program calls subroutine read_file and the debugger crashes where indicated.

Thanks in advance for any insights. This problem is preventing my organization from upgrading to the new compiler!

Code is too long to fit in a single post. I'll post 'code' in subsequent post(s)

module MyModule

use OtherModule ! ←- defines MyTYPE

type MyOtherTYPE integer :: ThereAreManyVars end type MyOtherTYPE

type(MyOtherTYPE), dimension(:), pointer :: compdat ⇒ null()

subroutine read_file() type(MyTYPE) :: info logical :: error character(len=80) :: tag character(len=80) :: starttag logical :: endtag character(len=80), dimension(1:2,1:20) :: attribs integer :: noattribs character(len=200), dimension(1:100) :: data integer :: nodata logical :: has_compdat

has_compdat = .false. allocate(compdat(0))

call read_00(info, tag, endtag, attribs, noattribs, data, nodata, & compdat, has_compdat )

end subroutine read_file

subroutine read_00(info, tag, endtag, attribs, noattribs, data, nodata, & dvar, has_dvar) type(MyTYPE) :: info character(len=), intent(inout) :: tag logical, intent(inout) :: endtag character(len=), dimension(:,:), intent(inout) :: attribs integer, intent(inout) :: noattribs character(len=*), dimension(:), intent(inout) :: data integer, intent(inout) :: nodata type(MyOtherTYPE), dimension(:), pointer :: dvar logical, intent(inout) :: has_dvar

integer :: newsize type(MyOtherTYPE), dimension(:), pointer :: newvar

newsize = size(dvar) + 1 allocate( newvar(1:newsize) ) newvar(1:newsize-1) = dvar deallocate( dvar ) dvar ⇒ newvar

call read_01( info, tag, endtag, attribs, noattribs, data, nodata, & dvar(newsize), has_dvar )

end subroutine read_00

subroutine read_01( info, starttag, endtag, attribs, noattribs, data, nodata, & dvar, has_dvar ) type(MyTYPE) :: info character(len=), intent(in) :: starttag logical, intent(inout) :: endtag character(len=), dimension(:,:), intent(inout) :: attribs integer, intent(inout) :: noattribs character(len=*), dimension(:), intent(inout) :: data integer, intent(inout) :: nodata type(MyOtherTYPE), intent(inout) :: dvar logical, intent(inout) :: has_dvar character(len=80) :: tag

call getInfo( info, tag, endtag, attribs, noattribs, data, nodata ) ! ←-- Debugger throws Error 15 here as written

end subroutine read_01

end module MyModule

module OtherModule

type MyTYPE integer :: ThereAreManyVars end type MyTYPE

subroutine getInfo( info, tag, endtag, attribs, no_attribs, & data, no_data )

type(MyTYPE), intent(inout) :: info character(len=), intent(out) :: tag logical, intent(out) :: endtag character(len=), intent(out), dimension(:,:) :: attribs integer, intent(out) :: no_attribs character(len=*), intent(out), dimension(:) :: data integer, intent(out) :: no_data

endtag = .false. ! ←- if don't declare arg intent, debugger throws Error 15 here

end subroutine getInfo

end module OtherModule

Be warned that this forum only permits about 100 lines of code in a post, and the part beyond that limit gets removed.

Instead, zip up the sources, data and include files, if any, and instructions to build and run, upload the zip file to a cloud server such as Dropbox, make the uploaded file accessible to everyone, and post a link to it here.

My post 'Ex Code 00' has everything I intended to post. Can you discern anything from that?

It will be very labor intensive to build an executable program that exhibits the problem - I'm just having a problem in a single subroutine of a large program.

Thank you for any help!

Your two module sources are missing CONTAINS lines. I added those, and wrote the following trivial driver:

program tst
use MyModule
call Read_File()
end program

When I compiled with /checkmate /64, using FTN95 8.66, and ran the program inside SDBG64, it completed normally. The conclusion is that the code that you supplied does not exhibit the abnormal behaviour that you described, so there is nothing that I can do until you provide a reproducer.

Consider the debugger as just another program. The input to it is the output of the compiler and the linker. For most inputs from a larger number of users, the debugger performs correctly and as expected.

One can admit that there are some inputs for which it fails; some of us have reported such failures, and those have resulted in fixes to the debugger and/or the compiler and linker.

Without a reproducible failure to work with, what can the developers do?

Thank you for the feedback, and as a developer myself I understand your point.

Nonetheless, as a paying customer it seems to me that the burden of effort belongs to the party who broke the debugger tool (Silverfrost) not me who is trying to create productive work using the tool.

What's a developer to do? Review the changes made between v8.50 and v8.61 to determine what would cause the debugger to throw spurious Error 15 on an assignment statement.

What's a customer to do? I think just revert to v8.50 and miss out on the features I was looking forward to in v8.61.

I'll try find some time to devote to troubleshooting the problem, creating demo program to share, etc. and will create a new thread if I can manage to do that.

I don't intend to be disrespectful or rude - I really do see your point. I hope you can see my perspective too. This is just yet another in a series of Silverfrost releases which place a burden of debugging and testing on me (customer).

Again just to emphasize: There's nothing wrong with my code - it has worked for a long time. The problem is in the latest compiler working with the latest debugger.

Clay, I am just a user, too, and the comments that I wrote are from that viewpoint. Let us wait and see if Silverfrost have other recommendations.

Clay

It makes all the difference if you can supply code for a working program that demonstrates the failure. If you are unable to cut it down, can you zip it up and put it on DropBox (say).

Quoted from Clay There's nothing wrong with my code - it has worked for a long time

This is a claim that can be challenged !

I extracted your code above and it did not compile. You have a problem that the module definitions are out of order, so if you change 'OtherModule' and recompile, MyModule will see the old version. As noted, you have also omitted 'contains' from both modules.

Try and provide a reproducer for the behaviour you are reporting. Then both Silverfrost and other users may be able to assist.