D System v0.6: Fixed Bugs

Master Listing

{Can you reproduce the problem? (y/n)} y
{If yes, how to reproduce:}

        run checker on a correct Fortran source file with
        some loops in it.

{Can you work around the problem? (y/n)} n

{Detailed Problem Description:}

        The options for the program 'checker' include "-d",
which is supposed to get it to compute and save the dependence
graph for the module in question (at least this is what it says
it's supposed to do in the programs usage message). When I 
run it, it computes the dependence graph just fine (and prints it),
but doesn't save the dependence graph. 

{Suggested fix (optional):}

On October 4, 1994, John Mellor-Crummey (johnmc@cs.rice.edu) 
added the following:

::The reason checker (and every other tool in the DSystem) 
::don't save dependence graphs is that the dependence graph 
::I/O was not written using the former ParaScope/Rn conventions 
::so when the database/repository was replaced, porting the 
::dependence graph I/O became a significant task. Since the 
::dependence graph is marked for reimplementation by Ken,
::porting the dependence graph I/O seems like a poor investment 
::of effort to me. If anyone has a compelling reason to want to 
::attempt it anyway, I'd be glad to advise what needs to be done.

::The documentation on checker that says it prints out the dependence
::graph is erroneous and will be fixed.


{Date:} October 3rd, 1994

{Name and email address:} Nathaniel McIntosh (mcintosh@cs.rice.edu)
{Organization:} Rice University

{Program:} D System     {Version:} [0.6]    
{Report Type (1-6):} 2 Design Error - change the specification or design approach.

{Attachments (1-3):} 1 Isolated source code (and data) that reproduce the problem.

{Internal use only.  Please do not write below this line.}
{--------------------------------------------------------}

Assigned to: Kevin Cureton 10/94

Resolved by: Kevin Cureton (curetonk@cs.rice.edu) on or 
before 3/15/1995. Corrections will appear in v0.7.

{Can you reproduce the problem? (y/n)} yes
{If yes, how to reproduce:} see description

{Can you work around the problem? (y/n)} no

{Detailed Problem Description:}

   This bug has to do with the way that the dependence
analyzer builds its list of references for a given loop.
Consider the following loop (from SPEC77):

      DO 3 I=1,JCAP1
      WRITE(6,101) (A(I,J), J=1,JCAP1)

When the dependence analyzer looks at the "i" loop, it sees
the reference to "j" in the "j=1" part of the WRITE
statement as a use of the scalar variable "j", as opposed
to what it should be (i.e. a definition of a new induction
variable for the implied DO). This can screw things up
later on with variable privatization (since the privatizer
tries to treat that "j" as a use, and can't get the right
SSA information on it).


{Suggested fix (optional):}

The fix for this is to handle implied DO's as a special
case in the routine dg_stmt_refs(). Should be a no-brainer.

{Date:}  Sept 27, 1994

{Name and email address:} N. McIntosh (mcintosh@cs.rice.edu)
{Organization:} Rice University

{Program:} D System     {Version:} [0.6] 

{Report Type (1-6):} 2 {Design Error - change the specification or design approach.}

{Attachments (1-3):} 1 {Isolated source code (and data) that reproduce the problem}

{Internal use only.  Please do not write below this line.}
{--------------------------------------------------------}

Resolved by: Nat McIntosh (mcintosh@cs.rice.edu) on or 
before 3/15/1995. Corrections will appear in v0.7.

This bug was reported and corrected by Nat McIntosh (mcintosh@cs.rice.edu), who added that it may not be completely resolved and may still involve module consistency checking.

Version 0.6 of the D System contains a bug in the
code which examines compositions. Compositions are
checked for consistency (i.e. to detect duplicate
function definitions and unresolved function 
references, etc), but the specific errors are not
printed when they occur. Instead, a single catch-all
message is printed indicating that some errors are present.

In Version 0.7, if a program composition file has
consistency problems, the specific errors (i.e. duplicate
definitions, unresolved references, etc) can be seen
by running the composition through the "checker" with 
the -P option. 

Modified files in this bug fix include

        execs/checker/Checker.C
        libs/fileAttrMgmt/composition/Composition.h
        libs/fileAttrMgmt/composition/ErrorsCompAttr.C
        libs/fileAttrMgmt/composition/ErrorsCompAttr.h
        libs/fileAttrMgmt/composition/NeedProvCompAttr.C
        libs/fileAttrMgmt/composition/NeedProvCompAttr.h
        libs/fileAttrMgmt/composition/ProcModuleMap.h
        libs/fileAttrMgmt/composition/Composition.C
        libs/frontEnd/ast/NeedProvSet.C

Note that other tools within the D System 
(examples: cfg, fortDcompiler) will still detect composition 
consistency problems, but will not report the specific 
errors ("checker"  is required for this purpose).

In Version 0.6 of the D System, the code which supports
nested compositions (i.e. compositions within
compositions) is buggy. Specifically, the facility that
checks the nested composition for consistency is
incorrect and will fail to detect certain consistency
problems if they appear in nested compositions. 

This bug was reported by Nat McIntosh (mcintosh@cs.rice.edu) and corrected by Kevin Cureton (curetonk@cs.rice.edu) in v0.7.

When you run one of the D tools like fortD or checker, it spits 
out a copyright notice, which includes the following:

   Usage of this software implies acceptance 
   of the licenses which can be found in
   /DSystem/LicenseDSystem and /DSystem/LicensePablo 
   or retrieved from the World Wide Web, using the URL 
   http:/softlib.rice.edu/fortran-tools/DSystem/v0.6

The URL listed above is malformed. It should be 
 
    http://softlib.rice.edu/fortran-tools/DSystem/v0.6
not 
    http:/softlib.rice.edu/fortran-tools/DSystem/v0.6

D System Home Page - Software & Documentation - Unresolved Bugs

URL ftp://softlib.rice.edu/pub/DSystem/Release-0.6/bugIndexFixed-0.6.html