Failure to detect undefined variable(s) even with /undef specified

When a subroutine is entered, any dummy argument that has the attribute intent(out) becomes undefined as soon as the subroutine is entered. Even if the corresponding actual argument is well defined before the call, the corresponding dummy argument becomes undefined after the subroutine is entered. The decade old US Navy/NASA program HWM14 contains a troublesome bug that may be attributed to not knowing this behaviour. It took considerable effort to track this down, and in this case FTN95, despite its well-deserved reputation for detecting errors, failed to pinpoint the error. I created a short, if silly, test code to point out the issue. The code:

program demo
implicit none
integer :: iw(2)
iw(1)=2; iw(2)=3
call sub(iw)
print *,iw
end program

subroutine sub(jw)
implicit none
integer,intent(out) :: jw(2) ! wrong intent, makes jw undefined
jw(2)=2*jw(1)
jw(1)=jw(1)+jw(2)
return
end subroutine

Compile and link with /undef and run. No error messages!

Lahey Fortran 7.1 catches the bug:

S:\>demo
jwe0323i-w line 9 The variable (jw(1)) has an undefined value.
 error occurs at _sub_    line 9 loc 0040117c offset 00000069
 _sub_        at loc 00401113 called from loc 004010ba in _MAIN__      line 4
 _MAIN__      at loc 00401000 called from o.s

The NAG compiler, with its C=undefined -gline options, also catches the error:

Runtime Error: demo.f90, line 12: Reference to undefined variable JW(1)
Program terminated by fatal error
demo.f90, line 12: Error occurred in SUB
demo.f90, line 5: Called by DEMO

mecej4

Thank you for the feedback.

My first thought was that there is a missing interface in the code (sub uses INTENT(IN) so requires an interface when called from the main program).

But it turns out that you get the failure report with FTN95 when using /checkmate. I think that it ought to fail when using /undef alone soI will log this for investigation.

My first thought was that there is a missing interface...in the code (sub uses INTENT(IN) so requires an interface

Regardless of what intents were <mis>stated, this example code is not one in which any interface is required. There is no requirement for intents to be stated at all. I look forward to being able to catch the bug with just /undef, thanks.

mecej4

Thank you for correcting my mistake. An interface is required when a dummy argument has assumed shape and this is not the case here. I was thinking along the lines that the compiler would need this information in order to set the INTENT(OUT) array to "undefined" but this appears not to be the case.

FTN95 has been changed for the next release so that this check will be implemented when using /undef. I presume that the original motivation to limit this to /checkmate (i.e. /full_undef) was concern about the overhead incurred when initialising large arrays. In future, if users want to use /undef without this particular check, they can add /inhibit_check 14.