D System v0.6: Unresolved Bugs

To report a bug in the D System v0.6, please download the D System Bug Report Form, edit it with your favorite editor, and email it to dsystem-info@cs.rice.edu.

Index

• StatAnal-100494.1 Static analysis assigns incorrect and/or inappropriate storage classes to variables in FORTRAN programs.

• CFG-040595.1 Composition errors caught but not printed.

• Compiler-040595.1 (Edited 3/18/96.)

• Checker-040595.2 Code involving nested compositions doesn't work correctly.

• ProgEnv-042095.1 dmakes involving template repositories require multiple compiles.

• Checker-050895.1 Compositions without PROGRAMs generate a checker error.

• Compiler-061395.1 Default processor number not set.

• Compiler-061395.2 Compiler doesn't handle differing block sizes.

• CFG-062195 (Retracted on 06/27/95. Removed on 3/18/96.)

• DepTester-092895 Dependence tester flunks array refs in loop bounds.

Master Listing

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

        program main
          implicit real*8 (a-h,o-z)
          common /io/ in, iout, ipunch
          equivalence (approx, oldsum)
          approx = 1.0
          oldsum = 2.0
          print *, approx
        end

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

{Detailed Problem Description:}

        In the above program fragment, approx and oldsum are assigned
        to static storage.  This is not required by the language
        definition.  Worse, it is inadvisable.  These variables should
        be allocated to the stack.  Making them static forces inclusion
        of additional memory references.  For any program that uses
        large local arrays, this decision can drastically increase its
        dynamic storage requirements.

        In the above program, the name /io/ is assigned a storage class
        of "static" or "save".  /io/ is a common block name; it has no
        storage associated with it.  This is wrong.

        In the above program, the names in, iout, and ipunch are correctly
        assigned the storage class global.  Unfortunately, they appear to
        be equivalenced, with /io/ as their equivalence class leader.  This
        is wrong; First, /io/ has no storage.  Second, in, iout, and ipunch
        are not involved in an equivalence.  Third, it suggests that an
        equivalence exists between global and static storage.  This cannot
        happen.  The entire equivalence class must reside in a single
        location.

        This overactive and unnecessary use of static storage is the primary
        thing that prevents us from making recursive calls to code compiled
        using the D tools for analysis.  It isn't clear to me why D cares about
        the distinction between static allocation and stack allocation.  If
        it is going to care, it should make the distinction in an appropriate
        and informed way.

{Suggested fix (optional):} Go back to the way this code worked for years.

{Date:} 4 October 1994

{Name and email address:} Keith D. Cooper (keith@cs.rice.edu)
{Organization:}  Rice University

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

{Report Type (1-6):} 2 or 3 {Design Error - change the specification or design approach; or Coding Error - a logic error or coding typo; maybe i = 2 should be i < 2.}

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

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

Severity (1-4):
1-Minor - not inhibiting, tolerable
2-Serious - need to fix eventually (incorrect behavior)
3-Critical - need to fix in next release or send patch (work inhibiting)
4-Fatal - system failure (crashes, aborts)

Assigned to:

Resolution Code (1-8):
1-Fixed
2-Can't reproduce it
3-Would require substantial effort to fix
4-Deferred until a later release
5-Withdrawn by submitter
6-Works to spec, misunderstanding
7-Disagree with suggestion
8-Developed workaround

Explanation of Resolution (this may go back to the user):

Resolved by:
Resolution tested by:
Resolution version:

Location/name of test case:

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". 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). 

See CFG-040595.1.

[index]

Checker-040595.2 Code involving nested compositions doesn't work correctly.

Reported by Nat McIntosh (mcintosh@cs.rice.edu).

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. Please 
avoid using nested compositions for the time being

Start conditions:
A directory that uses templates:
/home/marka/PipeLine/obj/SunOS-5.x/libs/fortD/performance/tuning
A set of templates (for vectors): my libs/support/vectors directory
A template repository: obj/SunOS-5.x/libs/templates/Templates.DB

Start: rm .d_ files, *.a files, etc. in tuning
rm * in the template repository

dmake in tuning
crunch along and get:

/home/marka/PipeLine/obj/SunOS-5.x/libs/templates -xar 
/home/marka/PipeLine/src/libs/fortD/performance/tuning/PipeTuneSupport.C 
-o FortD-SunOS-5.x-g.a
"/home/marka/PipeLine/src/libs/support/vectors/TemplateVector.C", 
line 352: Error: Could not find source for 
operator<<(ostream&, PipeTimingInfo&).
1 Error(s) detected.

Note the file that defines PipeTimingInfo (StatisticsRepository.{C,h})
has not yet been compiled.

dmake again, just builds PipeTuneSupport.C, and gives same error
repeat dmake, same error
repeat dmake, same error

rm .d_ files, *.a files, etc. in tuning <-- magic happens here....
dmake again, rebuilds all from scratch..., things work properly.

Apparently there is stuff in the template repository that needs to 
be initialized the first time and is not.

If I reorder the the file list in the Makefile so that the .C file 
for PipeTimingInfo is listed before that of PipeTuneSupport, things 
still act the same... 

However, this introduces an element of fragility that I just don't 
like. And I don't understand how the repeated compile fixes things. 
I have a list of files that are modified in the second compile, but 
I'm really not sure what they mean.

And I'm having nightmareish problems with the static RCS_ID variables 
my Assertion system wants and the template system, but I won't go into 
that right now.

One other interesting thing is that sometimes missing symbol complaints 
can be due to a error in a class derived from a template instance:

class IntVector : TemplateVector<int{
public:
      IntVector();
      ~IntVector();
}

If the destructor of TemplateVector is virtual and IntVector is not,
then it complains about undefined symbols being referenced.

Bug description: if you write a composition which doesn't contain a
PROGRAM (i.e. it only has subroutines), the checker will report that
there is an error, but won't tell you what the error is. Here is the
error message you get:

  Checker error: Some modules in composition comp have errors...

which is less than perfect. It should obviously print out a gripe
about having no "main" routine or PROGRAM.

Report Type: 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: Default processor number not set

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

See the attached source Fortran D program.

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

Detailed Problem Description:

The following Fortran D source

 c     test program to see how partitioning algorithms work in fortD
       program test
 c     decomposition d(200)
       integer a(200)
 c     align a with d
 c     distribute d(block)
       do i=2, 100
          a(i) = 5
       enddo
       end

produces the following target code:

       program test
         integer a(-200)
 C       
 C       --<< Fortran D variable declarations >>--
         common /FortD/ n$p, my$p, my$pid
         integer n$p, my$p, my$pid, numnodes, mynode, mypid, phys2log
 C       
 C       --<< Fortran D initializations >>--
         n$p = numnodes()
         if (n$p .ne. (-1)) stop
         my$p = phys2log(mynode())
         my$pid = mypid()
         if (my$p .eq. 0) then
           do i = 2, 100
             a(i) = 5
           enddo
         endif
       end

The target code is obviously incorrect and doesn't even compile with
the node Fortran compiler.  When the following line is added to the
source

 parameter (n$proc=...)

everything works just fine.

Program: fortD     Version: 0.6    Release: September 1994

Report Type: Design Error - change the specification or design approach.

Problem Summary: The compiler doesn't handle differing block sizes

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

        parameter (n$proc=8)
C       decomposition d(100)
C       distribute d(block)

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

[index]

DepTester-092895 Dependence tester flunks array refs in loop bounds.

Submitted by Nat McIntosh (mcintosh@cs.rice.edu)

Report Type (1-6): 2
  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): dependence tester flunks array refs in loop bounds

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

Can you work around the problem? (y/n) 
If yes, how to workaround: 

Detailed Problem Description:

  The dependence tester in V0.6 of the D system doesn't scan loop
bounds for potential array references. Strange dependence information
can result (with potentially unknown consequences). The following is
an example:

        program mumble
        integer i, j
        integer a(101), b(101), c(100,100)
        do i = 1, 100
          a(i+1) = b(i)
          do j = 1, a(i)
            c(i,j) = 0
          enddo
        enddo
        end

  When the dependence tester scans this loop for array references,
it doesn't pick up the reference to "a(i)" in the bounds expression of
the "j" loop. This can result in incorrect dependence info for the "i"
loop.

Suggested fix (optional):

  This bug is fixed in V0.7.


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

Bug Report # (Functional Area & date.counter, e.g., C051694.3)
  C-Compiler
  D-Documentation
  DA-Distribution Assistant
  DB-Debugger
  E-Editor
  UI-User Interface
  P-Performance Analyzer

Severity (1-4):
  1-Minor - not inhibiting, tolerable
  2-Serious - need to fix eventually (incorrect behavior)
  3-Critical - need to fix in next release or send patch (work inhibiting)
  4-Fatal - system failure (crashes, aborts)

Assigned to:

Resolution Code (1-8):
  1-Fixed
  2-Can't reproduce it
  3-Would require substantial effort to fix
  4-Deferred until a later release
  5-Withdrawn by submitter
  6-Works to spec, misunderstanding
  7-Disagree with suggestion
  8-Developed workaround

Explanation of Resolution (this may go back to the user):


Resolved by:
Resolution tested by:
Resolution version:

Location/name of test case:

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