VSI Fortran V8.7-001 for OpenVMS x86-64 Systems

1. Overview

VSI Fortran V8.7-001 for OpenVMS x86-64 systems runs on OpenVMS x86-64 V9.2-2 or later. OpenVMS V9.2-3 is strongly recommended.

VSI Fortran on OpenVMS x86-64 is based on VSI Fortran for OpenVMS IA-64. There may be platform-specific features from OpenVMS Alpha and OpenVMS IA-64 that may not be supported.

The image identification for the Fortran compiler is F90 V8.7-001.

The FORTRAN/VERSION string is:

VSI Fortran x86-64 V8.7-001 (GEM 50xxx) on OpenVMS x86_64 V9.2-3

2. Getting Help and Reporting Problems

Please report problems or offer feedback using the VSI Support Portal.

You can also send comments, questions and suggestions about the VSI Fortran product to info@vmssoftware.com. Note that this address is for informational inquiries and is not a formal support channel.

3. Corrections Since the Last Release

Added debug support for various structures. This fix requires the OpenVMS V9.2-3 debugger for best results. The VMS922X_DEBUG-V0200 update kit also provides limited support on OpenVMS V9.2-2 systems.
Various bug fixes for incorrect optimization.

4. Changes From OpenVMS Alpha and OpenVMS IA-64

4.1. Incompatible Change for Assigned GOTO Statements

OpenVMS x86-64 places code in 64-bit address space by default. Due to this change, assigning a label to INTEGER*4 variable will cause truncation of a 64-bit pointer to a 32-bit pointer and using GOTO may cause unexpected results or an access violation error. Change the program to use an INTEGER*8 variable or link with the /SEGMENT=CODE=P0 qualifier which will cause the code segments to be place in 32-bit address space. The compiler will now issue a warning message for using ASSIGN with an INTEGER*4 variable.

$ type assigngoto.for
        integer num

        assign 200 to num
        goto num

200     print *,'At 200'
        end
$ fort assigngoto

        assign 200 to num
......................^
%F90-W-WARNING, Storing label address to 32-bit integer may cause runtime errors.
at line number 3 in file DKA300:[DIR]ASSIGNGOTO.FOR;1

4.2. VAX D_floating May Produce Different Results Than IA-64

VAX D_floating values may produce slightly different results compared to Itanium. This is due to compiler-generated conversions to G_floating and then back to D_floating which removes 3 bits of mantissa. This is similar to Alpha where D_floating would always convert to G_floating before operations, this behavior on x86-64 is an acceptable behavior.

5. Known Issues

REAL*8 exponentiation does not signal correct errors for invalid operations.
Debug support is not fully implemented and the debugger may not fully understand Fortran datatypes.
Quadruple precision floating point (REAL*16, REAL(KIND=16), COMPLEX*16) is currently not supported. This will be addressed in a future release of the compiler along with changes to various system libraries.
The /MACHINE_CODE qualifier is ignored. As a workaround, you can use the ANALYZE/OBJECT/DISASSEMBLE to show the generated code and line numbers.

6. Known Restrictions

The SCA support with the /ANALYSIS_DATA qualifier is limited. The Fortran 95 compiler only produces basic SCA information about modules. It does not include information about variables and other symbols. This is a permanent restriction.

7. Features Missing From Documentation

IA64, _IA64_ , X86, And _X86_64_ predefine symbols are implemented.

8. Floating-Point Arithmetic

IEEE is the default floating-point datatype (that is, the default is /FLOAT=IEEE_FLOAT).
VSI Fortran for OpenVMS Alpha Systems defaults to the VAX G_float floating-point format (/FLOAT=G_FLOAT). On OpenVMS IA-64 or OpenVMS x86-64 systems, however, there is no hardware support for floating-point representations other than IEEE. Instead, the compiler supports VAX floating-point formats by generating run-time code which converts operands to IEEE format, performs the needed arithmetic operations, and then converts the IEEE result back to the appropriate VAX format.
Depending on the application, this may impose significant additional run-time overhead and some loss of accuracy compared to performing the operations in hardware on an Alpha.
This software support for the VAX formats is an important functional compatibility requirement for certain applications that need to deal with on- disk binary floating-point data, but its use should be strongly discouraged.
If at all possible, users should use /FLOAT=IEEE_FLOAT (the default) for the highest performance and accuracy.
Note that the changed /FLOAT default will have implications for the use of /CONVERT=NATIVE (the default). This switch causes unformatted data to remain unconverted on input, on the assumption that it matches the prevailing floating-point datatype.
Files written from Fortran applications built with /FLOAT=G_FLOAT/CONVERT=NATIVE (the default) on Alpha can be read by Integrity server applications built with /FLOAT=G_FLOAT/CONVERT=NATIVE or /FLOAT=IEEE/CONVERT=VAXG.
The /IEEE_MODE qualifier defaults to /IEEE_MODE=DENORM_RESULTS This differs from Alpha, where the default is /IEEE_MODE=FAST. Despite the name, /IEEE_MODE=FAST does not have a significant effect on run-time performance on Integrity or x86-64 servers (or on Alpha processors from EV6 onward).
On Integrity or x86-64 servers, users will have to pick one compile-time /FLOAT value and one compile-time /IEEE_MODE value and stick with it for the whole of their application. This is because mixed-mode applications will not (in general) work on OpenVMS IA-64 or OpenVMS x86-64 systems as a result of architectural differences in the hardware. This is a change from OpenVMS Alpha systems, where mixed-mode applications work. In particular, per-routine/per-file/per-library settings of a mode will not work.
Exception handlers will be entered with the floating-point mode in effect at the time the exception was raised, not the mode with which the handler was compiled.

9. VSI Fortran Documentation and Online Information

The VSI Fortran documentation set can be found online at https://docs.vmssoftware.com/