D System v0.7: Fixed Bugs D System v0.7: Fixed BugsTo report a bug in the D System v0.7, please download the D System Bug Report Form, edit it with your favorite editor, and email it to dsystem-info@cs.rice.edu.
Typechecker-062395 Typechecker coercing references into triplets.
Reported by Nathaniel McIntosh (mcintosh@cs.rice.edu)
Report Type: 2/3
2-Design Error - change the specification or design approach.
3-Coding Error - a logic error or coding typo; maybe i = 2 should be i < 2.
Attachments: Isolated source code (and data) that reproduce the problem
Problem Summary: Typechecker problem with equivalences: The F90 support in the typechecker is coercing vanilla references inside "equivalence" statements into triplets, which is gumming up the works later on in the typechecker. Should be easy to fix.
Can you reproduce the problem? (y/n) y
If yes, how to reproduce:
The following program will reproduce the bug:
program mumble
integer b(100), q(100)
equivalence (b, q)
print *, 'hello world'
end
Can you work around the problem? (y/n) y
If yes, how to workaround:
Use subscripts instead of identifiers, i.e.
"equivalence (b(1), q(1))"
Detailed Problem Description:
As part of the Fortran 90 support, the typechecker
looks for unadorned array references (example: "a")
and converts them into triplet notation in the tree
(i.e. "a(:,:,:)"). This conversion is screwing
up the code which runs later in the typechecker
that post-processes equivalence statements.
Suggested fix (optional):
The code which performs the triplet conversion
needs to be a little more selective about the
references that it converts. It already checks for
a number of specific cases, but it needs to be
just a little more careful. Jerry and I have
discussed this briefly; I don't think it will
require a lot of work to fix.
Fixed by Jerry Roth (roth@cs.rice.edu) on 6/29/95.
Description of fix: In the typechecker, there is code to add F90 null
triplet subscripts to full array references. The problem was that it
was too aggressive and added subscripts in declaration statements,
etc. Since we are really only interested in adding the subscripts in
situations where the array reference does not make sense in F77 code, I
added a check to make sure the array reference under consideration is
an F90-only construct. This includes array assignment statements and
WHERE statements.
[index]
Reported by Nat McIntosh (mcintosh@cs.rice.edu).
Report Type (1-6): 3
1-Suggestion - nothing's broken; you just want to suggest an improvement.
2-Design Error - change the specification or design approach.
3-Coding Error - a logic error or coding typo; maybe i = 2 should be i < 2.
4-Documentation Error - the program and the documentation don't agree.
5-Question - how do you make the software do x?
6-Hardware - the software's having trouble working with the hardware.
Attachments (1-3): 1
1-Isolated source code (and data) that reproduce the problem
2-Core file
3-Other (corrected documentation)
Problem Summary (one line): cfg routine slightly buggy
Can you reproduce the problem? (y/n)
If yes, how to reproduce:
To reproduce the problem, run the following Fortran
program through "ipdriver -A -P comp":
program driv
integer str(100)
call bug(str, 90, 20)
end
subroutine bug(a, n, m)
integer n, i, m
integer a(n)
if (a(i) .eq. 0) go to 20
return
20 do i = 1, m
a(i) = 0
enddo
return
end
Can you work around the problem? (y/n)
If yes, how to workaround:
Avoid using "goto"'s that jump to DO loop headers.
Detailed Problem Description:
The routine "cfgval_loop_from_ast()" appears not to work if
you pass it a DO loop that is in turn the target of a goto.
The CFG node map returns the CFG node of the label (the "preheader")
not of the loop, resulting in a crash.
Suggested fix (optional):
cfgval_loop_from_ast() is currently implemented as a macro; I
think the best thing to do is rewrite it as a subroutine,
and have it check for the case above.
Fixed by Nat McIntosh (mcintosh@cs.rice.edu) on 11/22/95.
[index]
Reported by Nat McIntosh (mcintosh@cs.rice.edu).
There is a minor bug in the CFG package (thanks to
Mark Anderson for providing the Fortran program that flushed it out).
The bug is as follows: the routine cfgval_loop_from_ast() does not
work properly if you pass it the AST node for a DO loop that is the
target of a "go to". Example:
subroutine flarp(a, n, m)
integer n, i, m
integer a(n)
if (a(i) .eq. 0) go to 99
return
99 do i = 1, m
a(i) = 0
enddo
return
end
Note the "do" loop with label 99. If you invoke cfgval_loop_from_ast()
on this loop, it will return NULL, since it thinks you're asking for
the loop information for the "preheader" node (i.e. the target of the
goto) and not the actual loop header.
When I get the chance, I'll rewrite cfgval_loop_from_ast (it is
currently a macro) to test for this case and do the right thing. In
the mean time, consider yourself warned.
Fixed by Nat McIntosh (mcintosh@cs.rice.edu) on 11/22/95.
[index]
URL ftp://softlib.rice.edu/pub/DSystem/Release-0.7/bugIndexFixed-0.7.html