SGI IRIX Problems
The following are known problems with this platform:
Arrays in main Are Not Found Unless Declared in common
If an array is declared in main, the SGI MIPSpro 7.3.3 compiler does not create debugging information for the variable. Consequently, TotalView does not know that the array exists. You can workaround this problem by placing the array in a common block.
Attaching To SHMEM Jobs Is Not Supported
TotalView does not support attaching to SHMEM jobs. If you try, you may not see all of the job's processes and the process leader may not be properly identified; this could hang your job.
Bad Template Names May Be Generated
Because of a compiler bug in the SGI 7.2 and 7.2.1 compilers, bad template type names may be generated for certain template instantiations. This problem is fixed by Patch 3492: MIPSpro 7.2.1 C++ front-end rollup #4, which is available at the SGI Support Web Site.
Cray Pointers in common Blocks Broken
The debugging information generated by SGI 7.3 Fortran compiler for the targets of Cray pointers contained within common blocks contains the wrong address. Here is an example:
common a1(1000)
common /ptrs/ jj,iparray,kk
pointer (iparray,array)
iparray = loc(a1)
end
array is a real variable that is the target of the Cray pointer iparray. Because the address is wrong, TotalView cannot show you the correct values for the iparray variable. This bug has been reported to SGI. (The SGI 7.2.1 and earlier versions of the compiler do not have this bug.)
Evaluation System Cannot Access Fortran 90 Up-level Variables
Access to F90 up-level variables does not work in the evaluation system. Because of SGI F90 7.2.1 and earlier compiler bugs, access to F90 up-level variables does not work from EVAL expressions. Those variables are correctly located and displayed in data panes, however.
This problem should be fixed in the MIPSpro F90 7.3.1.2 compiler.
Evaluation System Forces Real Function Result into a long Temporary
When a program is compiled with the Fortran 90 compiler, the TotalView expression evaluation system erroneously converts real function results. The SGI Fortran 90 compiler fails to emit the return type of the function, so TotalView assumes that the return type of the function is a long. When assigned to a real variable, the return result of the function is erroneously converted from a long to a real, when in fact the function had already returned a real. Here is an example:
real function x_to_the_y_power(x, y)
TotalView expression:
real result
result = x_to_the_y_power(2.0, 4.0)
This problem, which does not occur with the Fortran 77 compiler, has been reported to SGI. (pr 2296)
Formal Parameter Target Cannot be Shown
Because of SGI 7.2.1 F90 compiler bugs, when that compiler is generating debugging information, TotalView can not show the target of a formal parameter Cray pointer. Consider the following code:
subroutine rex (rp)
pointer (rp, p(8))
p(2) = 6.
P(5) = 3.
write (*,*) "Should be 6,3 - ",p(2), p(5)
return
end
In this example, the compiler generates debugging information for p without any addressing information.
This problem should be fixed in the MIPSpro F90 7.3.1.2 compiler.
Fortran 90 Pointer Variables Not Correctly Identified
F90 pointer variables are not correctly identified as pointers because of incomplete debugging information generated by the compilers. TotalView displays the target data correctly, however.
This problem should be fixed in the MIPSpro F90 7.3.1.2 compiler.
Fortran Arrays With Runtime Bounds Display Problem
Some Fortran arrays with runtime bounds are displayed improperly. Because of a limitation in the debug output produced by the SGI Fortran 90 compilers, this happens for arrays which are the targets of pointers embedded in a user-defined type which has itself been arrayed. Consider the following:
type array_ptr
real, dimension (:), pointer :: ap
end type array_ptr
type (array_ptr), allocatable, dimension (:) :: arrays
allocate (arrays(20))
do i = 1,20
allocate (arrays(i)%ap(i))
end do
TotalView reports the bounds of the elements arrays%ap incorrectly because the compiler has generated invalid debug information for the runtime bounds.
This problem should be fixed in the MIPSpro F90 7.3.1.2 compiler.
#include and -cpp Used Together in Fortran 90
If source files contain #include statements and are compiled with the -cpp switch on a Fortran 90 program using the MIPSpro compilers, TotalView generates incorrect line numbers. To avoid this problem, use the standard Fortran include statement (without the -cpp switch).
KCC Does Not Put Original File Name Into Symbol Table
IRIX KCC code: TotalView fails to put the original file name (before preprocessing) into the symbol table. This prevents you from asking for the file by name until TotalView processes all the file's symbols.
If you use the --keep_gen_c option to the KCC compiler, you can use the following TotalView command: f xxx.int.c (where your original source file was xxx.C) to force full symbol processing of that file, after which you'll be able to do f xxx.C.
main Not Found by TotalView
TotalView will not find a Fortran 90 main program. TotalView will not display any source code if you do not use a PROGRAM statement within a Fortran 90 program. You can correct this problem by adding a PROGRAM statement to your main program. (pr 2099)
Pointers With Unlimited Bounds Shown With Bound of 1
Because of SGI 7.2.1 F90 compiler bugs, when that compiler is generating debugging information, TotalView shows the target of Cray pointers with unlimited bounds as having an upper bound of 1. Consider the following code:
subroutine test (ixx, n)
common /sf/ iptr
pointer (iptr, ita(*))
... etc ...
end
In this example, the compiler generates debug information for ita that indicates it has an upper bound of 1. This is incorrect because it has an unlimited upper bound.
Single-stepping Inadvertently into System Routines
The single-step commands sometimes step into system routines.
Source Code Not Found For System Routines Complaint
TotalView occasionally complains about not being able to find the source code for system routines (such as printf()).
Virtual Base Classes: Showing Multiple Instances
Because of SGI 7.1 C++ compiler bugs, when that compiler is generating debugging information, TotalView shows multiple instances of virtual base classes. Normally only one instance is correct, which is the one that is of type pointer to the base class.
