Sun Studio 10 FAQ

To reduce the size of the Sun Performance Library for Sun Studio 10, only the so.4 libraries have been included, and the legacy so.2 and so.3 libraries have been removed from this release.

To maintain compatibility with applications that require the legacy so.2 and so.3 libraries, the Sun Studio 10 packages will search for previous installations of the Sun Performance Library on the system and install symlinks to the location of the previously installed libraries. If no prior Sun Performance Library packages are found, the Sun Studio 10 packages will install only the current so.4 libraries. To have symlinks to the legacy libraries, you will need to install the legacy packages before installing the Sun Performance Library for Sun Studio 10 packages.

All the versions of the Sun Performance Library are available for download at no cost through the Sun Download Center. The legacy libraries for a particular version of Sun Performance Library are also located on the Forte Developer product CD for that release. For example, the packages for the Forte Developer 6 update 2 release are located in /cdrom/cdrom0/products/packages.

» See Example

You can install one or more of the packages, based upon your needs.

If the legacy libraries have not been installed before installing Sun Studio 10 and you want the symlinks to the legacy libraries, you will need to do the following:

• Uninstall the Sun Studio 10 Shared Performance Library packages
• Install the legacy shared packages
• Install the Sun Studio 10 shared packages

To install the legacy packages use the pkgadd command. See the pkgadd man page for usage instructions. (When installing to a location other than the default, carefully read the pkgadd man page section describing the "-a" option. For example, the "-a none" option will force an interactive install.)

Make sure you include the USE SUNPERF statement in the source that is making calls to the Performance Library from F95. The USE statement must appear after the PROGRAM statement and before any other statement (aside from other USE statements).

PROGRAM MyProgram USE SUNPERF ...

The F95 compiler will only search the current directory for module files specified in a USE statement. You can cause the compiler to search additional directories by adding the -M option to the compilation line.

f95 -o mytest mytest.f -xlic_lib=sunperf -M/opt/SUNWspro/lib

NOTE: At this time, the f95 compiler will not search architecture specific directories for the correct sunperf.mod file. If you are compiling executables with -xarch set any of the v9 architectures, you must use the specific architecture path so that the compiler will pick up the correct sunperf.mod file.

Example:

f95 -o mytest mytest.f-xlic_lib=sunperf-xarch=v9a-M/opt/SUNWsproc/lib/v9a

This error is caused when an attempt is made to call one of the Performance Library routines through the F95 generic interfaces but the parameter list used does not match any of the interfaces provided. F95 implements polymorphism with a technique known as "ad-hoc" polymorphism. This means that while it appears that a given routine is being called through a common interface, what is actually happening is that a number of interfaces are created and the compiler matches the calling sequence with one of the existing interfaces. The error described above indicates that the parameter list used in calling one of the supported routines is different from any parameter list in the sunperf.mod file.

• The fully specified parameter list is always supported.
• Parameters that describe array strides and leading dimensions can always be left off.
• Work arrays and the parameters that describe the size of a work array can always be left off.
• Parameters that describe array dimension sizes can usually (but not always) be left off.
• Parameters of the same type occurring adjacent to one another in the parameter list will always appear or not appear as a group.
• INFO parameters can always be omitted.

Example 1:

SUBROUTINE CAXPY(N,ALPHA,X,INCX,Y,INCY)
Supported calling sequences:
CALL AXPY(N,ALPHA,X,INCX,Y,INCY) <-- Rule #1 fully specified
CALL AXPY(N,ALPHA,X,Y=Y) <-- Rule #2 array strides omitted
CALL AXPY(ALPHA=ALPHA,X=X,Y=Y) <-- Rule #4 array dimension omitted

NOTE: The first letter of the routine name is left off since the routine type is controlled by the type of the ALPHA, X, and Y parameters. There is no support for interfaces that mix floating point or complex type parameters in the same parameter list (i.e., you may not call AXPY with an ALPHA of type REAL*4 and an X or Y type of REAL * 8).

Example 2:

SUBROUTINE DGELQF(M,N,A,LDA,TAU,WORK,LDWORK,INFO)
Supported calling sequences:
CALL GELQF(M,N,A,LDA,TAU,WORK,LDWORK,INFO) <- Rule #1
CALL GELQF(M,N,A,TAU=TAU,INFO=INFO) <- Rule #2, #3
CALL GELQF(A=A,TAU=TAU,INFO=INFO) <- Rule #2,#3,#4,#5
CALL GELQF(A=A,TAU=TAU) <- Rule #2,#3,#4,#5,#6

NOTE: Once a parameter is omitted, successive parameters must use the "pass-by-name" convention for correct function. Parameter names match those listed in the corresponding man pages.

The Performance Library has been compiled with the Sun F95 compiler to take advantage of many of the F95 language features. Because of this, the Performance Library makes calls to the F90 runtime system. When linking an C code with the Performance Library, you can get rid of the unsatisfied symbols in one of two ways:

• Compile with C and link with F95. This will cause the correct F90/F95 runtime routines to be linked.

  Example:

  cc -c faq_c.c -dalign
  f95 -o faq_c faq_c.o -xlic_lib=sunperf

• Add additional information to the C compile/link line to cause the correct F90/F95 runtime routines to be linked.

  Example:

  cc -o faq_c faq_c.c -xlic_lib=sunperf,fui,fai,fsu -dalign

The name of the include file for the Performance Library routines is sunperf.h and is in the compiler include directory.

Example:

If you installed your compilers at /opt/SUNWspro then the include file will have been installed at
/opt/SUNWspro/include/cc/sunperf.h.

The V9 version of the Performance Library contains both 32 and 64-bit interfaces to the supported computational routines. If the 32-bit interface is called, integer parameters are converted to 64-bit integers and the 64-bit routine is called. This means that there is a slight performance penalty for calling the 32-bit interfaces when linking with the V9 version of the Performance Library. The 64-bit interfaces can be called directly by appending _64 to the desired routine name.

Example 1:

INTEGER*4 N, INCX, INCY CALL
CAXPY(N,ALPHA,X,INCX,Y,INCY)

When linked to the V9 library, this will result in a call to a wrapper routine that will convert N, INCX, and INCY to 64-bit integers, followed by a call to the CAXPY_64 routine with the promoted parameters.

Example 2:

INTEGER*8 N, INCX, INCY
CALL CAXPY_64(N,ALPHA,X,INCX,Y,INCY

This call will directly call the 64-bit CAXPY routine when linked with the V9 version of the Performance Library.

NOTE: This interface does not exist in the V8 or V8PLUS versions of the Performance Library, so if you try this while compiling for those architectures you will get unsatisfied external references when linking.

Example 3:

INTEGER N, INCX, INCY
CALL CAXPY_64(N,ALPHA,X,INCX,Y,INCY)

This will directly call the 64-bit CAXPY routine when linked with the V9 version of the Performance Library. You *must* compile with the compiler flag -xtypemap=integer:64 or you will get undefined results. This is due to the fact that the 64-bit routines expect 64-bit integer parameters.

You may be experiencing stack overflow in your program. There are two types of stack space that need to be addressed.

First, there is the stack space allocated to a process. This is controlled by the limit command. Try unlimiting your process stack by saying:

% unlimit stacksize

Secondly, if your program is multi-threaded each thread must have its own stack space. This is controlled by the ${STACKSIZE} environment variable. The units are in KB so saying:

% setenv STACKSIZE 4000

sets each thread's stack size to 4 MB. This is the minimum value that Performance Library requires, so make sure that ${STACKSIZE} is set to at least 4000. You may need to increase this value if your program uses large stack based variables.

Forte Developer 6 update 2 was the last release that included LINPACK in the Sun Performance Library. LAPACK version 3.0, which supersedes LINPACK and all previous versions of LAPACK, is provided instead. If legacy user codes that call LINPACK routines cannot be modified to use LAPACK routines, the public domain version of LINPACK can still be obtained from Netlib. The LINPACK routines that were removed are listed in the Table.