Compaq Fortran
Release Notes for Compaq Tru64 UNIX Systems
Previous Contents

1.8.4 Known Problems

1.8.4.1 "Variable used before its value has been defined" Warning

The compiler may inappropriately issue a "Variable is used before its value has been defined" warning. If the variable named in the warning does not appear in your program (e.g. var$0354), you should ignore the warning.

1.8.4.2 Mask Expressions Referencing Multiple FORALL Indices

FORALL statements containing mask expressions referencing more than seven FORALL indices do not work properly.

1.8.5 Unsupported Features

This section lists unsupported features in this release of Compaq Fortran.

1.8.5.1 SMP Decomposition (OpenMP) not Currently Compatible with HPF

Manual decomposition directives for SMP (such as the OpenMP directives enabled with the -omp option, or the directives enabled with the -mp option) are not currently compatible with the -wsf option.

1.8.5.2 Command Line Options not Compatible with the -wsf Option

The following command line options may not be used with the -wsf option:

1.8.5.3 HPF_LOCAL Routines

Arguments passed to HPF_LOCAL procedures cannot be distributed CYCLIC(n). Furthermore, they can have neither the inherit attribute nor a transcriptive distribution.

Also, the following procedures in the HPF Local Routine Library are not supported in the current release:

1.8.5.4 SORT_UP and SORT_DOWN Functions

The SORT_UP and SORT_DOWN HPF library procedures are not supported. Instead, use GRADE_UP and GRADE_DOWN, respectively.

1.8.5.5 Restricted Definition of PURE

In addition to the restrictions on PURE functions listed in the Fortran 95 language standard and in the High Performance Fortran Language Specification, Compaq Fortran adds the additional restriction that PURE functions must be resident. "Resident" means that the function can execute on each processor without reading or writing any data that is not local to that processor.

Non-resident PURE functions are not handled. They will probably cause failure of the executable at run-time if used in FORALLs or in INDEPENDENT DO loops.

1.8.5.6 Restrictions on Procedure Calls in INDEPENDENT DO and FORALL

In order to execute in parallel, procedure calls from FORALL and DO INDEPENDENT constructs must be resident. "Resident" means that the function can execute on each processor without reading or writing any data that is not local to that processor. The compiler requires an explicit assertion that all procedure calls are resident. You can make this assertion in one of two ways:

  1. by labeling every procedure called by the FORALL or INDEPENDENT DO loop as PURE
  2. by encapsulating the entire body of the loop in an ON HOME RESIDENT region.

Because of the restricted definition of PURE in Compaq Fortran (see Section 1.8.5.5), the compiler interprets PURE as an assertion by the program that a procedure is resident.

Unlike procedures called from inside FORALLs, procedures called from inside INDEPENDENT DO loops are not required to be PURE. To assert to the compiler that any non-PURE procedures called from the loop are resident, you can encapsulate the entire body of the loop in an ON HOME RESIDENT region.

If you incorrectly assert that a procedure is resident (using either PURE or ON HOME RESIDENT), the program will either fail at run time, or produce incorrect program results.

Here is an example of an INDEPENDENT DO loop containing an ON HOME RESIDENT directive and a procedure call: 


!HPF$ INDEPENDENT 
DO i = 1, 10 
   !HPF$ ON HOME (B(i)), RESIDENT  BEGIN 
   A(i) = addone(B(i)) 
   !HPF$ END ON 
END DO 
. 
. 
. 
 
CONTAINS 
  FUNCTION addone(x) 
    INTEGER, INTENT(IN) :: x 
    INTEGER addone 
    addone = x + 1 
  END FUNCTION addone

The ON HOME RESIDENT region does not impose any syntactic restrictions. It is merely an assertion that inter-processor communication will not actually be required at run time.

For More Information:

1.8.5.7 Restrictions on Routines Compiled with -nowsf_main

The following are restrictions on dummy arguments to routines compiled with the -nowsf_main compile-time option:

Failure to adhere to these restrictions may result in program failure, or incorrect program results.

1.8.5.8 RAN and SECNDS Are Not PURE

The intrinsic functions RAN and SECNDS are serialized (not executed in parallel). As a result, they are not PURE functions, and cannot be used within a FORALL construct or statement.

1.8.5.9 Nonadvancing I/O on stdin and stdout

Nonadvancing I/O does not work correctly on stdin and stdout . For example, this program is supposed to print the prompt ending with the colon and keep the cursor on that line. Unfortunately, the prompt does not appear until after the input is entered. 


PROGRAM SIMPLE 
 
 
        INTEGER STOCKPRICE 
 
        WRITE (6,'(A)',ADVANCE='NO') 'Stock price1   : ' 
        READ  (5, *) STOCKPRICE 
 
        WRITE (6,200) 'The number you entered was ', STOCKPRICE 
200     FORMAT(A,I) 
 
 
END PROGRAM SIMPLE

The work-around for this bug is to insert a CLOSE statement after the WRITE to stdout . This effectively flushes the buffer. 


PROGRAM SIMPLE 
 
 
        INTEGER STOCKPRICE 
 
        WRITE (6,'(A)',ADVANCE='NO') 'Stock price1   : ' 
        CLOSE (6)                        ! Add close to get around bug 
        READ  (5, *) STOCKPRICE 
 
        WRITE (6,200) 'The number you entered was ', STOCKPRICE 
200     FORMAT(A,I) 
 
 
END PROGRAM SIMPLE

1.8.5.10 WHERE and Nested FORALL

The following statements are not currently supported:

When nested DO loops are converted into FORALLs, nesting is ordinarily not necessary. For example, 


DO x=1, 6 
  DO y=1, 6 
    A(x, y) = B(x) + C(y) 
  END DO 
END DO

can be converted into 


FORALL (x=1:6, y=1:6)  A(x, y) = B(x) + C(y)

In this example, both indices (x and y) can be defined in a single FORALL statement that produces the same result as the nested DO loops.

In general, nested FORALLs are required only when the outer index is used in the definition of the inner index. For example, consider the following DO loop nest, which adds 3 to the elements in the upper triangle of a 6 x 6 array: 


DO x=1, 6 
  DO y=x, 6 
    A(x, y) = A(x, y) + 3 
  END DO 
END DO

In Fortran 95/90, this DO loop nest can be replaced with the following nest of FORALL structures: 


FORALL (x=1:6) 
  FORALL (y=x:6) 
    A(x, y) = A(x, y) + 3 
  END FORALL 
END FORALL

However, nested FORALL is not currently supported in parallel (i.e. with the -wsf option).

A work-around is to use the INDEPENDENT directive: 


      integer, parameter :: n=6 
      integer, dimension (n,n) :: A 
!hpf$ distribute A(block,block) 
 
      A = 8 
 
      !hpf$ independent, new(i) 
      do j=1,n 
         !hpf$ independent 
         do i=j,n 
            A(i,j) = A(i,j) + 3 
         end do 
      end do 
 
      print "(6i3)", A 
 
      end

All three of these code fragments would convert a matrix like this:
<left[ symbol><matrix symbol> 8&8&8&8&8&8<cr symbol> 8&8&8&8&8&8<cr symbol> 8&8&8&8&8&8<cr symbol> 8&8&8&8&8&8<cr symbol> 8&8&8&8&8&8<cr symbol> 8&8&8&8&8&8<cr symbol> <right] symbol>

into this matrix:
<left[ symbol><matrix symbol> 11&11&11&11&11&11<cr symbol> 8&11&11&11&11&11<cr symbol> 8&8&11&11&11&11<cr symbol> 8&8&8&11&11&11<cr symbol> 8&8&8&8&11&11<cr symbol> 8&8&8&8&8&11<cr symbol> <right] symbol>

1.8.6 Obsolete Features Deleted

1.8.6.1 GLOBAL_TO_PHYSICAL and GLOBAL_LBOUNDS are Deleted

The following obsolete HPF Local Library routines have been deleted:

1.8.7 Miscellaneous

This section contains miscellaneous release notes relevant to HPF.

1.8.7.1 What To Do When Encountering Unexpected Program Behavior

This section gives some guidelines about what to do when your program displays unexpected behavior at runtime. The two most common problems are incorrect programs that either segmentation fault or hang at runtime.

Before attempting to debug parallel HPF programs, it is important to verify first that the program runs correctly when compiled without the -wsf command line switch.

When the problem occurs only when compiled with the -wsf switch, the best way to debug these programs is to execute them with the -debug command line switch.

In addition, programs with zero sized arrays which were compiled with -fast or -assume nozsize may behave erratically or fail to execute.

1.8.7.1.1 Incompatible or Incomplete Libraries Installed

If your program displays unexpected behavior at runtime, your system might have incomplete or incompatible libraries installed. You must have PSE160 installed on your system to execute programs compiled with the -wsf switch. PSE180 is not sufficient. In addition, for this release, you must have first installed PSE160. Then you must have installed Fortran V5.2, including the HPFLIBS170 subset.

Choose one of the following options to fix an incorrect installation:

For more information about installing PSE160, see the Compaq Parallel Software Environment Release Notes, Version 1.6.

For more information about installing PSE180, see the Compaq Parallel Software Environment Release Notes, Version 1.8.

1.8.7.1.2 Segmentation Faults

When a program segmentation faults at runtime it can be confusing because it may look like the program executed, even though no output is produced. The PSE does not always display an error message when the return status of the executed program is non zero. In particular, if the program segmentation faults it does not display an error message, the program just stops. In this example, program "bad" gets a segmentation fault at runtime. 


# bad -peers 4 
#

To see the execution status, type this csh command (other shells require different commands): 


# echo $status

A status of -117 indicates a segmentation fault. See the section about known problems in the Parallel Software Environment (PSE) Version 1.6 release notes.

Alternatively, you can run the program in the debugger. This is better because it shows what went wrong on each peer. To do this, use the -debug command line switch. 


# bad -peers 4 -debug

See Chapter 9 of the DIGITAL High Performance Fortran 90 HPF and PSE Manual for more information.

Note that some correct programs may segmentation fault at runtime due to lack of stack space and data space. See Section 1.8.7.2 for further details.

1.8.7.1.3 Programs that Hang

If your program hangs at runtime, rerun it in the debugger. You can type <ctrl>/c in the debugger to get it to stop. Then look at the stack frames to determine where and why the program is hanging. Programs can hang for many reasons. Some of the more common reasons are:

It is always best to compile, run, and debug the program without the -wsf switch first to verify program correctness. Since it is easier to debug scalar programs than parallel programs, this should always be done first.

1.8.7.1.4 Programs with Zero Sized Arrays

Programs with zero sized arrays should not be compiled with the -fast or the -assume nozsize command line switches; see Chapter 8 in the DIGITAL High Performance Fortran 90 HPF and PSE Manual. If you incorrectly compile this way there are several different types of behavior that might occur. The program might return an error status of -122 or -177 or 64 . It might also hang (or timeout when the -timeout switch is used). Try compiling the program without these options and execute it to see if it works correctly. If it does, there is most likely a zero-sized array in the program.

1.8.7.2 Stack and Data Space Usage

Exceeding the available stack or data space on a processor can cause the program execution to fail. The failure takes the form of a segmentation violation, which results in an error status of -117. (See the section about known problems in the Parallel Software Environment (PSE) Version 1.6 release notes.) This problem can often be corrected by increasing the stack and data space sizes or by reducing the stack and data requirements of the program. The following csh commands increase the sizes of the stack and data space up to system limits (other shells require different commands): 


limit stacksize unlimited 
limit datasize  unlimited

If your system limits are not sufficient, contact your system administrator, and request that maxdsiz (the data space limit) and/or maxssiz (the stack limit) be increased.

1.8.7.3 Non-"-wsf" main programs

The ability to call parallel HPF subprograms from non-parallel (Fortran or non-Fortran) main programs, is supported in this release. For more information, see Chapter 6 of the DIGITAL High Performance Fortran 90 HPF and PSE Manual.

1.8.7.4 Using "-std" Disables HPF Directive Checking

Normally, all HPF directives are checked for syntactic and semantic correctness regardless of whether or not the -wsf switch is specified. To disable this checking, specify the -std option.

1.8.7.5 Use the Extended Form of HPF_ALIGNMENT

Due to an anomaly in the High Performance Fortran Language Specification, the extended version of the HPF_ALIGNMENT library routine (High Performance Fortran Language Specification V.2 Section 12.2) is incompatible with the standard version (High Performance Fortran Language Specification V.2 Section 7.7).

In particular, the DYNAMIC argument, which is valid only in the extended version, is not the final argument in the argument list.

Because each compiler vendor must choose to implement only one version of this library routine, programs that use this routine are not portable from one compiler to another unless keywords are used for each of the optional arguments.

Compaq chooses to support the extended version of this library routine.

1.8.7.6 EXTRINSIC(SCALAR) Changed to EXTRINSIC(HPF_SERIAL)

EXTRINSIC(SCALAR) was renamed to EXTRINSIC(HPF_SERIAL) to be compatible with Versions 1.1 and later of the High Performance Fortran Language Specification. EXTRINSIC(SCALAR) continues to be supported in this release, but may not be supported in future releases.

1.8.8 Example Programs

The /usr/examples/hpf directory contains example Fortran programs. Most of these programs are referred to in the HPF Tutorial section of the DIGITAL High Performance Fortran 90 HPF and PSE Manual. Others are just there to show examples of HPF code and PVM code. The provided makefile can be used to compile all these programs.

1.9 New Features and Corrections in Version 5.1

Version 5.1 is a major release that includes corrections to problems discovered since Version 5.0 was released.

The following topics are discussed:

1.9.1 Version 5.1 New Features

The following new Compaq Fortran (DIGITAL Fortran 90) features are now supported:

Previous Next Contents