D System v0.7: Fixed Bugs

Master Listing

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.

See CFG-112195.2.

[index]

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.

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