Compaq Fortran
Release Notes for Compaq Tru64
UNIX Systems
1.11.3 Preliminary Information on Support for Big Objects
Big objects are data items whose size cannot be
represented by a signed 32 bit integer. Compaq Fortran supports larger
objects than Compaq Fortran 77.
Big objects are good for massive machines and clusters used for
numerical analysis, such as weather forecasting and high energy physics
problems. Both special knowledge and very large hardware configurations
are needed to use this feature.
Your system and its operating system must be configured to:
- Allow a very large stack space.
- Allow a very large data space.
- Allow large values for parameters, such as vm-maxvas.
- Unless huge amounts of physical memory are present, enable lazy
swapping.
- Check the size of page/swap files and create larger files if needed.
For more information, see the Compaq Tru64 UNIX system management
documentation. For Compaq Tru64 UNIX Version 4.0, you can use the
following check list:
- Either have a large swap space or use deferred swap allocation.
This involves either:
- Have more swap space than the address space used by the largest
program you want to run. The following command shows swap allocation:
- Use the deferred mode of swap allocation. The following command
displays the reference (man) page for swapon, which describes how to
change the swap allocation
- Reconfigure the UNIX kernel (for Version 4.0 or later) to change
the following parameters as desired. For example, on one system, all
values were set to 16 GB:
Parameter |
Explanation |
max-per-proc-address-space
|
Largest address space
|
max-per-proc-data-size
|
Largest data size
|
max-per-proc-stack-size
|
Largest stack size
|
vm-maxvas
|
Largest virtual-memory
|
Also set the following per-process values:
Parameter |
Explanation |
per-proc-address-space
|
Default address space
|
per-proc-data-size
|
Default data size
|
per-proc-stack-size
|
Default stack size
|
The per-process limits can be checked and increased with the
limit
or
ulimit
commands.
You can create big objects as static data, automatic data (stack), or
dynamically allocated data (ALLOCATE statement or other means).
The address space limitations depends on the Alpha processor generation
in use:
- Address space for ev4 Alpha generation processors is 2**42
- Address space for ev5 Alpha generation processors is 2**46
Although the compiler produces code that computes 63-bit signed
addresses, objects and addresses larger than the hardware limitations
will not work.
Limitations of using big objects include:
- Initializing big objects by using a DATA statement or a TYPE
declaration is not supported.
- Big objects cannot be passed by value as program arguments.
- Debug support for big objects is limited.
- I/O of entire big objects is not supported, but I/O of parts of an
array should work.
The following small example program allocates a big character object:
character xx(2_8**31+100_8)
integer*8 i
i = 10
xx(i) = 'A'
i = 2_8**31 + 100_8
xx(i) = 'B'
print *,xx(10_8)
print *,xx(i)
end
|
1.11.4 New Random Number Algorithm
A new random_number intrinsic (Version 4.0 or later) uses a different
algorithm than the one previously used.
The test program below shows the use of the random_seed and
random_number intrinsics.
program testrand
intrinsic random_seed, random_number
integer size, seed(2), gseed(2), hiseed(2), zseed(2)
real harvest(10)
data seed /123456789, 987654321/
data hiseed /-1, -1/
data zseed /0, 0/
call random_seed(SIZE=size)
print *,"size ",size
call random_seed(PUT=hiseed(1:size))
call random_seed(GET=gseed(1:size))
print *,"hiseed gseed", hiseed, gseed
call random_seed(PUT=zseed(1:size))
call random_seed(GET=gseed(1:size))
print *,"zseed gseed ", zseed, gseed
call random_seed(PUT=seed(1:size))
call random_seed(GET=gseed(1:size))
call random_number(HARVEST=harvest)
print *, "seed gseed ", seed, gseed
print *, "harvest"
print *, harvest
call random_seed(GET=gseed(1:size))
print *,"gseed after harvest ", gseed
end program testrand
|
When executed, the program produces the following output:
% testrand
size 2
hiseed gseed -1 -1 171 499
zseed gseed 0 0 2147483562 2147483398
seed gseed 123456789 987654321 123456789 987654321
harvest
0.6099895 0.9807594 0.2936640 0.9100146 0.8464803
0.4358687 2.5444610E-02 0.5457680 0.6483381 0.3045360
gseed after harvest 375533067 1869030476
|
1.11.5 Compaq Fortran 77 Pointers
Compaq Fortran 77 pointers are CRAY® style pointers, an extension
to the Fortran 90 standard. The POINTER statement establishes pairs of
variables and pointers, as described in the Compaq Fortran Language Reference Manual.
1.11.6 Extended Precision REAL (KIND=16) Floating-Point Data
The X_float data type is a little endian IEEE-based format that
provides extended precision. It supports the REAL*16 Compaq Fortran Q
intrinsic procedures. For example, the QCOS intrinsic procedure for the
generic COS intrinsic procedure.
The value of REAL (KIND=16) data is in the approximate range:
6.475175119438025110924438958227647Q-4966 to
1.189731495357231765085759326628007Q4932.
Unlike other floating-point formats, there is little if any performance
penalty from using denormalized extended-precision numbers, since
accessing denormalized numbers do not result in an arithmetic trap
(extended-precision is emulated in software). (The smallest normalized
number is 3.362103143112093506262677817321753Q-4932.)
The precision is approximately one part in 2**112 or typically 33
decimal digits.
The X_float format is emulated in software. Although there is no
standard IEEE little endian 16-byte REAL data type, the X_float format
supports IEEE exceptional values.
For more information, see the revised Compaq Fortran User Manual for Tru64 UNIX and Linux Alpha Systems and the
Compaq Fortran Language Reference Manual.
1.11.7 Variable Format Expressions (VFEs)
By enclosing an arithmetic expression in angle brackets, you can use it
in a FORMAT statement wherever you can use an integer (except as the
specification of the number of characters in the H field). For example:
For more information, see the Compaq Fortran Language Reference Manual.
1.11.8 Notes on Debugger Support
Compaq Tru64 UNIX provides both the
dbx
and the Compaq Ladebug (formerly DECladebug) debuggers in the
programming environment subsets.
These debuggers are very similar and use almost identical set of
commands and command syntax. Both have a command-line interface as well
as a Motif® windowing interface.
A character-cell Ladebug (ladebug) interface is provided with Ladebug
in the Compaq Tru64 UNIX operating system Programmer's Development
Toolkit. To use the character-cell interface, use the
ladebug
command.
When using Ladebug with certain versions of the UNIX operating system,
be aware that a trailing underscore may be needed to display module
variables. For example, to display variable X in module MOD, type:
The Parallel Software Environment supports debugging parallel HPF
programs (see the DIGITAL High Performance Fortran 90 HPF and PSE Manual). This section addresses scalar
(nonparallel) debugging.
When using the
f90
command to create a program to be debugged using
dbx
or
ladebug
, consider using the following options:
- Specify
-g
or
-g2
to request symbol table and traceback information needed for debugging.
- Avoid requesting optimization. When you specify
-g
or
-g2
, the optimization level is set to
-O0
by default. Debugging optimized code is neither easy nor recommended.
- When using the Ladebug debugger, you should specify the
-ladebug
option. The
-ladebug
option allows you to print and assign to dynamic arrays using standard
Fortran syntax.
For example, the following command creates the executable program
proj_dbg.out
for debugging with Ladebug:
% f90 -g -ladebug -o proj_dbg.out file.f90
|
You invoke the character-cell Ladebug debugger by using the
ladebug
command.
For more information, see the debugger chapter in the revised
Compaq Fortran User Manual for Tru64 UNIX and Linux Alpha Systems (Chapter 4).
1.11.8.1 Ladebug Debugger Support Notes
The following improvements in Ladebug support for the Compaq Fortran
language were added for DIGITAL UNIX Version 4.0:
- Ladebug now includes a graphical window interface.
- Ladebug now supports the display of array sections.
- Ladebug now displays Fortran data types using Fortran 90 name
syntax rather than C names (such as integer rather than int).
- Ladebug provides improved support for debugging mixed-language C
and Fortran applications.
- These and other improvements are described in the debugger chapter
(Chapter 4) of the Compaq Fortran User Manual for Tru64 UNIX and Linux Alpha Systems.
The following improvements in Ladebug support for the Fortran 90
language were added for DEC OSF/1 Version 3.2 (DECladebug V3.0-16):
- Fortran and Fortran 90 language expression evaluation is built into
the Ladebug command language, including:
- Case-insensitive identifiers, variables, program names, and so on
- Logical expressions, including:
Relational operators (.LT., .LE., .EQ., .NE., .GT., .GE.)
Logical operators (.XOR., .AND., .OR., .EQV., .NEQV., .NOT.)
- Fortran 90 pointers
- Fortran 90 array support, including:
- Explicit-shape arrays
- Assumed-shape arrays
- Automatic arrays
- Assumed-size arrays
- Deferred-shape arrays
- COMMON block support, including:
- Display of whole common block
- Display of (optionally-qualified) common block members
- COMPLEX variable support, including the display, assignment, and
use of arithmetic expressions involving COMPLEX variables
- Alternate entry points, including breakpoints, tracepoints, and
stack tracing (
where
command)
- Mixed-language debugging
For more information on using Ladebug, see the debugger chapter in the
revised Compaq Fortran User Manual for Tru64 UNIX and Linux Alpha Systems (Chapter 4).
1.11.8.2 dbx Debugger Support Notes
When using
dbx
with Compaq Fortran programs, certain differences exist. For example, in
dbx
, assumed-shape arguments, allocatable arrays, and pointers to arrays
are printed as a derived type. Consider the following program:
module foo
real x
contains
subroutine bar(a)
integer a(:)
a(1) = 1
end subroutine bar
end module foo
use foo
integer b(100)
call bar(b)
end
|
If the above program were stopped inside BAR, the following would occur:
(dbx) print a
common /
dim = 1
element_length = 4
ptr = 0x140000244
ies1 = 4
ub1 = 10
lb1 = 1
/
|
The meaning of the fields are:
dim - dimension of the object
element_length - the length of each element in bytes
ptr - the address of the object
iesn - distance (in bytes) between elements in the
nth dimension
ubn - upper bound in the nth dimension
lbn - lower bound in the nth dimension
1.11.9 Notes on Fast Math Library Routines
The
f90
option
-math_library fast
provides alternate math routine entry points to the following:
- SQRT, EXP, LOG, LOG10, SIN, and COS intrinsic procedures
- Power (**) in arithmetic expressions
1.11.10 The Compaq Fortran Array Descriptor Format
In the Compaq Fortran User Manual for Tru64 UNIX and Linux Alpha Systems, Chapter 10, Section 10.1.7 describes the Compaq
Fortran array descriptor format.
These notes are an initial attempt to provide a template for those C
programmers creating an a .h file that lays out the Fortran array
descriptor format.
There are two varying parameters for this descriptor format:
- The element type (shown in this section as <ELEMENT_TYPE> )
- The rank (shown in this section as <RANK> )
Common information for all descriptors is the general layout of the
header and the information for each dimension.
One possible C @codefont(struct) definition for the per-dimension
information is:
struct _f90_array_dim_info {
int inter_element_spacing;
int pad1;
int upper_bound;
int pad2;
int lower_bound;
int pad3;
};
|
The inter-element spacing is measured in 8-bit bytes, not in array
elements. This presents a challenge in designing array descriptor
definitions in C, since there is no completely clean way to interact
with C's pointer arithmetic.
One way to design the struct definition for an array descriptor is to
use the template:
struct _f90_array_desc_rank<RANK>_<NAME_TOKEN> {
unsigned char dim;
unsigned char flags;
unsigned char dtype;
unsigned char class;
int pad;
long length;
<ELEMENT_TYPE> * pointer;
long arrsize;
void * addr_a0;
struct _f90_array_dim_info dim_info[<RANK>];
};
|
Where <RANK>, <NAME_TOKEN> and <ELEMENT_TYPE> are the
template parameters. Often <NAME_TOKEN> and <ELEMENT_TYPE>
can be the same, but in cases where <ELEMENT_TYPE> has
non-identifier characters in it (for example, space or star) then a
suitable <NAME_TOKEN> should be devised.
The problem with this approach is that the element addressing, which
uses the inter-element spacing, generates an offset in bytes. In order
to use C's native pointer arithmetic, either casts need to be done or a
division. For example:
- Casting:
*((<ELEMENT_TYPE> *) (((char *) desc->pointer) + byte_offset))
|
- Division:
(desc->pointer)[byte_offset/sizeof(<ELEMENT_TYPE>)]
|
Another way to design the struct definition for an array descriptor is
to use the template:
struct _f90_array_desc_rank<RANK>_general {
unsigned char dim;
unsigned char flags;
unsigned char dtype;
unsigned char class;
int pad;
long length;
char * pointer;
long arrsize;
void * addr_a0;
struct _f90_array_dim_info dim_info[<RANK>];
};
|
An advantage to this approach is that the same definition can be used
for all arrays of the same rank. The problem with this approach is that
it forces the programmer to cast:
*((<ELEMENT_TYPE> *) (desc->pointer + byte_offset))
|
Another approach is to remove <RANK> from the template as well,
yielding:
struct _f90_array_desc_general {
unsigned char dim;
unsigned char flags;
unsigned char dtype;
unsigned char class;
int pad;
long length;
char * pointer;
long arrsize;
void * addr_a0;
struct _f90_array_dim_info dim_info[7];
};
|
On the last line, 7 is used since that is the maximum rank allowed by
Fortran. Since the dim field should be checked, this definition can be
used in many (perhaps most) of the places a rank-specific definition
would be used, provided the programmer is aware that the dim_info
fields beyond the actual rank are undefined.
One place such a definition should NOT be used is when an object of
this definition is used as part of an assignment. This usage is
considered rare. For example:
void
ptr_assign_buggy(struct _f90_array_desc_general * ptr,
struct _f90_array_desc_general * tgt)
{
*ptr = *tgt;
}
|
Example of Array Descriptor Format Use
In this example, we have a 'struct tree' and a procedure
prune_some_trees_() that takes a descriptor of a rank=3 array of such
structs and calls prune_one_tree_() on each individual tree (by
reference):
void
prune_some_trees(struct _f90_array_desc_general * trees)
{
if (trees->dim != 3) {
raise_an_error();
return;
} else {
int x,y,z;
int xmin = trees->dim_info[0].lower_bound;
int xmax = trees->dim_info[0].upper_bound;
int xstp = trees->dim_info[0].inter_element_spacing;
int ymin = trees->dim_info[1].lower_bound;
int ymax = trees->dim_info[1].upper_bound;
int ystp = trees->dim_info[1].inter_element_spacing;
int zmin = trees->dim_info[2].lower_bound;
int zmax = trees->dim_info[2].upper_bound;
int zstp = trees->dim_info[2].inter_element_spacing;
int xoffset,yoffset,zoffset;
for (z = zmin, zoffset = 0; z <= zmax; z+= 1, zoffset += zstp) {
for (y = ymin, yoffset = 0; y <= ymax; y+= 1, yoffset += ystp) {
for (x = xmin, xoffset = 0; x <= xmax; x+= 1, xoffset += xstp) {
struct tree * this_tree =
(struct tree *) (trees->pointer + xoffset+yoffset+zoffset);
prune_one_tree_(this_tree);
}
}
}
}
}
|
Compaq would appreciate feedback on which definitions of array
descriptors users have found most useful.
Note that the format for array descriptors used by HPF is more
complicated and is not described at this time.
Chapter 2
New Features for Compaq Fortran Versions 4.n, 2.0, and 1.n Releases
This chapter summarizes the new features for Compaq Fortran Versions
prior to Version 5.0:
2.1 New Features and Corrections in Version 4.1
Version 4.1 is a maintenance release that contains a limited number of
new features and corrections to problems discovered since Version 4.0
was released.
For additional information added to these release notes for Version
4.1, see Section 1.11.3.
The following new features have been added for DIGITAL Fortran 90
Version 4.1:
- This release includes a partial implementation of the proposed
Fortran 95 standard.
The following features of the proposed Fortran
95 standard have been implemented by this version of DIGITAL Fortran 90
and are supported when using the
f90
or
f95
commands:
- FORALL statement and construct (implemented prior to Version 4.1)
- Automatic deallocation of ALLOCATABLE arrays (implemented prior to
Version 4.1)
- Dim argument to MAXLOC and MINLOC (implemented prior to Version 4.1)
- PURE user-defined subprograms (implemented prior to Version 4.1)
- ELEMENTAL user-defined subprograms (a restricted form of a pure
procedure)
- Pointer initialization (initial value)
- The NULL intrinsic to nullify a pointer
- Derived-type structure initialization
- CPU_TIME intrinsic subroutine
- Kind argument to CEILING and FLOOR intriniscs
- Enhanced SIGN intrinsic function
- Nested WHERE constructs, masked ELSEWHERE statement, and named
WHERE constructs
- Comments allowed in namelist input
- Generic identifier in END INTERFACE statements
- Detection of Obsolescent and/or Deleted features listed in the
proposed Fortran 95 standard
For more information on Fortran 95 features, see the Section 1.11.2.
- The
f95
command is now available for use with the
-std
option:
- To perform standards conformance checking against the Fortran 90
standard, use the
f90
command with
-std
. Using
f90
with
-std
will issue messages for features (such as FORALL) that have recently
been added to the proposed Fortran 95 standard (as well as other
extensions to the Fortran 90 standard).
- To perform standards conformance checking against the Fortran 95
standard, use the
f95
command with
-std
. Using
f95
with
-std
will not issue messages for features (such as FORALL) that have been
added to the proposed Fortran 95 standard, but will issue messages for
extensions to the Fortran 95 standard.
For more information on Fortran 95 features, see the Section 1.11.2.
- The
-intconstant
option has been added.
Specify the
-intconstant
option to use DIGITAL Fortran 77 rather than Fortran 90 semantics to
determine kind of integer constants. If you do not specify
-intconstant
, Fortran 90 semantics are used.
Fortran 77 semantics require that
all constants are kept internally by the compiler in the highest
precision possible. For example, if you specify
-intconstant
, an integer constant of 14 will be stored internally as
INTEGER(KIND=8) and converted by the compiler upon reference to the
corresponding proper size. Fortran 90 specifies that integer constants
with not explicit KIND are kept internally in the default INTEGER kind
(KIND=4 by default).
Similarly, the internal precision for
floating-point constants is controlled by the
-fpconstant
option.
- The
-pad_source
option has been added.
Specify the
-pad_source
option to request that source records shorter than the statement field
width are to be padded with spaces on the right out to the end of the
statement field. This affects the interpretation of character and
Hollerith literals that are continued across source records.
The
default is
-nopad_source
, which causes a warning message to be displayed if a character or
Hollerith literal that ends before the statement field ends is
continued onto the next source record. To suppress this warning
message, specify the
-warn nousage
option.
Specifying
-pad_source
can prevent warning messages associated with
-warn usage
.
- The
-warn usage
option has been added.
Specify the
-warn nousage
option to suppress warning messages about questionable programming
practices which, although allowed, often are the result of programming
errors. For example, a continued character or Hollerith literal whose
first part ends before the statement field ends and appears to end with
trailing spaces is detected and reported by
-warn usage
.
The default is
-warn usage
.
- The
-arch keyword
option has been added.
This option determines the type of Alpha
chip code that will be generated for this program. The
-arch keyword
option uses the same keywords as the
-tune keyword
option.
Whereas the
-tune keyword
option primarily applies to certain higher-level optimizations for
instruction scheduling purposes, the
-arch keyword
option determines the type of code instructions generated for the
program unit being compiled.
DIGITAL UNIX Version 4.0 and
subsequent releases provide an operating system kernel that includes an
instruction emulator. This emulator allows new instructions, not
implemented on the host processor chip, to execute and produce correct
results. Applications using emulated instructions will run correctly,
but may incur significant software emulation overhead at runtime.
All Alpha processors implement a core set of instructions. Certain
Alpha processor versions include additional instruction extensions.
Supported
-arch
keywords are as follows:
-
-arch generic
generates code that is appropriate for all Alpha processor generations.
This is the default.
Running programs compiled with the generic
keyword will run all implementations of the Alpha architecture without
any instruction emulation overhead.
-
-arch host
generates code for the processor generation in use on the system being
used for compilation.
Running programs compiled with this keyword
on other implementations of the Alpha architecture might encounter
instruction emulation overhead.
-
-arch ev4
generates code for the 21064, 21064A, 21066, and 21068 implementations
of the Alpha architecture.
Running programs compiled with the ev4
keyword will run without instruction emulation overhead on all Alpha
processors.
-
-arch ev5
generates code for some 21164 chip implementations of the Alpha
architecture that use only the base set of Alpha instructions (no
extensions).
Running programs compiled with the ev5 keyword will
run without instruction emulation overhead on all Alpha processors.
-
-arch ev56
generates code for some 21164 chip implementations that use the byte
and word manipulation instruction extensions of the Alpha architecture.
Running programs compiled with the ev56 keyword might incur
emulation overhead on ev4 and ev5 processors, but will still run
correctly on DIGITAL UNIX Version 4.0 (or later) systems.
-
-arch pca56
generates code for the 21164PC chip implementation that uses the byte
and word manipulation instruction extensions and multimedia instruction
extensions of the Alpha architecture.
Running programs compiled
with the pca56 keyword might incur emulation overhead on ev4 and ev5
and ev56 processors, but will still run correctly on DIGITAL UNIX
Version 4.0 (or later) systems.
- In addition to ev4, ev5, generic, and host, The ev56 and pca56
keywords are now supported for the
-tune
option.
The following new High Performance Fortran features have been added for
DIGITAL Fortran 90 Version 4.1:
- Transcriptive data distributions are now supported.
- The INHERIT directive can now be used to inherit distributions, as
well as alignments.
- Distributed components of user-defined types are now handled in
parallel. This is not part of standard High Performance Fortran (HPF),
but is an approved extension.
- The GLOBAL_SHAPE and GLOBAL_SIZE HPF Local Library routines are now
supported.
- There is a new compile-time option named
-show hpf
, which replaces the
-show wsfinfo
option. The
-show hpf
option provides performance information at compile time. Information is
given about inter-processor communication, temporaries created at
procedure boundaries, optimized nearest-neighbor computations, and code
that is not handled in parallel. You can choose the level of detail you
wish to see.
- New example programs are available in the following directory:
These new features are described in the DIGITAL High Performance Fortran 90 HPF and PSE Manual.
The corrections made for DIGITAL Fortran 90 Version 4.1 include the
following:
- Fix compiler abort with certain types of pointer assignment.
- Fix incorrect error message for nested STRUCTUREs.
- Fix inconsistent severity for undeclared variable message with
IMPLICIT NONE or command line switch.
- Fix incorrect error about passing LOGICAL*4 to a LOGICAL*1 argument.
- Add standards warning for non-integer expressions in computed GOTO.
- Do not flag NAME= as nonstandard in INQUIRE.
- Add standards warning for AND, OR, XOR intrinsics.
- VOLATILE attribute now honored for COMMON variables.
- Allow COMPLEX expression in variable format expression.
- Allow adjustable array to be declared AUTOMATIC (AUTOMATIC
declaration is ignored.)
- Honor
-automatic
(/RECURSIVE) in main program.
- Fix incorrect parsing error when DO-loop has bounds of -32768,32767.
- Fix compiler abort when extending generic intrinsic.
- Fix SAVEd variable in inlined routine that didn't always get SAVEd.
- Fix compiler abort with initialization of CHARACTER(LEN=0) variable
- Correct values of PRECISION, DIGITS, etc. for floating types.
- Fix incorrect value of INDEX with zero-length strings.
- Correct value for SELECTED_REAL_KIND in PARAMETER statement.
- Correct compile-time result of VERIFY.
- For OpenVMS only, routine using IARGPTR or IARGCOUNT corrupts
address of passed CHARACTER argument.
- Standards warning for CMPLX() in initialization expression.
- Fix compiler abort when %LOC(charvar) used in statement function.
- Fix incorrect initialization of STRUCTURE array.
- Fix compiler abort with large statement function.
- RESHAPE of array with a zero bound aborts at runtime.
- For OpenVMS only, /INTEGER_SIZE now correctly processed.
- SIZEOF(SIZEOF()) is now 8.
- Fix error parsing a derived type definition with a field name
starting with "FILL_".
- With OPTIONS /NOI4, compiler complained of IAND with arguments of
an INTEGER*4 variable and a typeless PARAMETER constant.
- Fix incorrect standards warning for DABS.
- Add error message for ambiguous generic.
- Corrected error parsing field array reference in IF.
- Bit constants in argument lists are typed based on value, not
"default integer".
- Allow module to use itself.
- Fix standards warning for Hollerith constant.
- For OpenVMS only, FOR$RAB is always INTEGER*4.
- For OpenVMS only, wrong values for TINY, HUGE for VAX floating.
- For OpenVMS only, EXPONENT() with /FLOAT=D_FLOAT references
non-existent math routine.
- The Compaq Fortran run-time library incorrectly failed to release
previously allocated memory when padding Fortran 90 input.
- The Compaq Fortran run-time library would incorrectly go into an
infinite loop when an embedded NULL character value was found while
performing a list-directed read operation.
- The Compaq Fortran run-time library would incorrectly treat an
end-of-record marker as a value separator while performing a
list-directed read operation.
- The Compaq Fortran run-time library incorrectly produced a
"recursive I/O operation" error after a user has made a call to flush()
to flush a unit which was not previously opened, then attempted to
perform any I/O operation on the unit
- The Compaq Fortran run-time library would incorrectly fail to
return an end-of-record error for certain non-advancing I/O operations.
This occurred when attempting to read into successive array elements
while running out of data.
- The Compaq Fortran run-time library, when it encountered the ":"
edit descriptor at the end of the input record did not stop reading the
next record, causing errors like "input conversion".
- The Compaq Fortran run-time library did not handle implied DO loops
on I/O lists when non-native file support (
-convert
or equivalent conversion method) was in use.
The following are corrections for HPF users in this version:
- Expanded I/O Support, including support for all features,
including: complicated I/O statements containing function calls,
assumed size arrays, or variables of derived types with pointer
components, and array inquiry intrinsics using the implied DO loop
index.
In addition, non-advancing I/O (except on stdin and stdout)
now works correctly if every PSE peer in the cluster has a recent
version of the Fortran run-time library (fortrtl_371 or higher).
- NUMBER_OF_PROCESSORS and PROCESSORS_SHAPE in EXTRINSIC(HPF_SERIAL)
routines
- Restriction lifted on user-defined types in some FORALLs
- Declarations in the specification part of a module
- EXTRINSIC(SCALAR) changed to EXTRINSIC(HPF_SERIAL)
These new corrections are described in more detail in the Parallel
Software Environment (PSE) release notes.