| Title: | Digital Fortran |
| Notice: | Read notes 1.* for important information |
| Moderator: | QUARK::LIONEL |
| Created: | Thu Jun 01 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1333 |
| Total number of notes: | 6734 |
COMPILER: Digital Fortran 77 V7.0-6-3245
OpenVMS Alpha DEBUG Version V6.2-103R
COMPILER: DEC Fortran V6.3-711-293V
OpenVMS Alpha DEBUG Version V7.1-000
The "SET BREAK %LINE NN" appears to ignore valid code lines. In the following
examples the error message %DEBUG-E-LINEINFO,... appears at all of the
'goto 999' statements.
Works as expected on OpenVMS VAX. Not sure if this is a Fortran or Debug issue.
$ fort/debug/list/noopt goto_test
$ link/debug GOTO_TEST
$ run goto_test
OpenVMS Alpha DEBUG Version V6.2-103R
%DEBUG-I-INITIAL, language is FORTRAN, module set to GOTO_TEST$MAIN
DBG> Set Mode Screen; Set Step Nosource
SRC: module GOTO_TEST$MAIN -scroll-source
6: end
7:
8: subroutine test (achar)
9: character*(*) achar
10:
-> 11: if (achar .eq. 'xyz') then
12: goto 999
13: endif
14:
15: if (achar .eq. 'xxx') then
16: achar = 'abc'
OUT -output
stepped to GOTO_TEST$MAIN\%LINE 5
stepped to GOTO_TEST$MAIN\TEST\%LINE 11
PROMPT -error-program-prompt
DBG> set break %line 12
%DEBUG-E-LINEINFO, no line 12, previous line is 11, next line is 15
DBG>
Code Example Follows:
Regards, John Griffin
Customer Support Center
implicit none
character*4 achar4 /'abc'/
call test (achar4)
end
subroutine test (achar)
character*(*) achar
if (achar .eq. 'xyz') then
goto 999
endif
if (achar .eq. 'xxx') then
achar = 'abc'
endif
if (achar .eq. 'abc') then
achar = 'def'
else
goto 999
endif
if (achar .eq. 'def') then
continue
goto 999
else
achar = 'def'
endif
999 continue
return
end
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1186.1 | The lessor of the evils | TLE::EKLUND | Always smiling on the inside! | Wed Feb 19 1997 16:49 | 30 |
Well, consider the generated code. In my compiler, there
is an instruction like: BNE R0, .999 which loosely corresponds
to the IF (...)THEN
GOTO999
Now what we have here is the option of associating this
instruction with either the IF statement or with the GOTO
statement. If the former (which is the current behavior),
then you get the behavior you didn't like. If the latter,
then the break will occur BEFORE the test, whether or not
the test is successful (whether or not we end up going to
line 999)! Surely the latter is MORE misleading.
It's a question of the least harmful behavior. The BNE
instruction, in some sense, "belongs" to both statements, but
is quite indivisible as far as the debugger is concerned. We
elected to take the least harmful path, which is to associate
the BNE with the IF statement, and this left NO code associated
with the GOTO, and hence no way to set a break on that
line. Strange, but that's just the way things turned
out...
Cheers!
Dave Eklund
PS Yes, it's true that we could have generated different code
sequences where there would be a separate test and GOTO, but
that's not likely to happen.
Dave E
| |||||