Causing breakpoints in Fortran pgm?

[AONym]

During the debugging process, I have Fortran code which checks certain conditions, and if they do not hold, I want the debugger to cause a break. Under CVF, I accomplished this by making an out-of-bounds array reference (array bounds checking turned on). For example,

INTEGER :: forceError(5)
IF(bad conditions) THEN
forceError(0)=1 ! gives debugger control
END IF

Is there a way to do this under IVF, say, a library subroutine that can be called?

I could, of course, just manually set breakpoints in the appropriate places, but it is more convenient to have a permanent breakpoint.

[Steven_L_Intel1]

The Win32 API routine DebugBreak.

[AONym]

This does cause a breakpoint (debugger gets control), but has one unfortunate feature: the call stack is missing the final entry (i e, the pgm that called DebugBreak), at least in CVF6.6/VS6.

[jimdempseyatthecove]

Then step out of the Windows debug break routine.

The technique I use is for conditions that would cause an abnormal end is to call a routine named DOSTOP. It looks something like this

SUBROUTINE DOSTOP(CVAR)
CHARACTER*(*) CVAR
WRITE(*,*) CVAR
! place break point here
STOP 'DOSTOP'
! Place next instruction here if you wish to continue
RETURN
END

Then I make a configuration which I call DebugFast which has the debug information enabled but everything else optimized. I make a run with the debugger (the application runs as fast as the Release version), but with a break point set at the STOP statement.

Sprinkled throught the program are sanity checks and ifa case of insanity is detected a call to DOSTOP is made with some appropriate text message (in the event theDebugger is not enabled).Example:

if(.not. associated(TOSS.ObjectPointer(nO).p)) CALL DOSTOP('MOD_TOSS - Invalid Object number')

When a bug is found I right-click on the RETURN and select set next statement at cursor. Then step out of the subroutine to get the context of the caller.

If I need additional information that what I can find when full optimizations areenabled in the routine that has the error, then I recompilethe caller with optimizations disabled.Then run again to debug the error. When the routine appears bug-free then I recompile with full optimizations.

Jim Dempsey