VSI Fortran V8.5-008 for OpenVMS x86 Systems Release Notes 25 January 2024 Copyright 2024 VMS Software, Inc. This document contains information about VSI Fortran V8.5-008 including new and changed features, differences between V8.5-008 and previous versions, corrections, and other topics. This file is of interest to both system managers and application programmers. CONTENTS CHAPTER 1 VSI FORTRAN V8.5-008 FOR OPENVMS X86-64 SYSTEMS RELEASE NOTES 1.1 Overview . . . . . . . . . . . . . . . . . . . . . 1-1 1.2 Getting Help And Reporting Problems . . . . . . . 1-1 1.3 Changes From OpenVMS Alpha And OpenVMS I64 . . . . 1-1 1.3.1 Incompatible Change For Assigned GOTO Statements 1-2 1.3.2 VAX D_floating May Produce Different Results Than I64 . . . . . . . . . . . . . . . . . . . . 1-2 1.4 Known Issues . . . . . . . . . . . . . . . . . . . 1-2 1.5 Features Missing From Documentation . . . . . . . 1-3 1.5.1 New /ALIGN=COMMONS=PAD_ALIGN_SIZE Qualifier . . 1-3 1.5.2 New /ASSUME=64BIT_STRING_PARAMS Qualifier . . . 1-3 1.5.3 IA64, _IA64_ , X86, And _X86_64_ Predefine Symbols Are Implemented. . . . . . . . . . . . . 1-4 1.6 Floating-Point Arithmetic . . . . . . . . . . . . 1-4 CHAPTER 2 VSI FORTRAN DOCUMENTATION AND ONLINE INFORMATION 2 CHAPTER 1 VSI FORTRAN V8.5-008 FOR OPENVMS X86-64 SYSTEMS RELEASE NOTES 1.1 Overview VSI Fortran V8.5-008 for OpenVMS x86-64 Systems provides a compiler which runs on OpenVMS x86-64 V9.2-1 or later. VSI Fortran V8.5-008 is the initial release of Fortran on OpenVMS x86-64. It is based on VSI Fortran on OpenVMS I64 for source compatibility. There may be platform-specific features from OpenVMS Alpha and OpenVMS I64 that may not be supported. The image identification for the Fortran compiler is F90 V8.5-008 The FORTRAN/VERSION string is VSI Fortran x86-64 V8.5-008 (GEM 50xxx) on OpenVMS x86_64 V9.2-1 1.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 these addresses are for informational inquiries and is not a formal support channel. 1.3 Changes From OpenVMS Alpha And OpenVMS I64 1-1 VSI FORTRAN V8.5-008 FOR OPENVMS X86-64 SYSTEMS RELEASE NOTES 1.3.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 1.3.2 VAX D_floating May Produce Different Results Than I64 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. 1.4 Known Issues - For user-defined routines that have the same name as a math function, for example ceil, which are called with literal arguments, the compiler might optimize away the call to the user-defined routine and replace it with the result of the actual MATH$ routine. 1-2 VSI FORTRAN V8.5-008 FOR OPENVMS X86-64 SYSTEMS RELEASE NOTES - Some conversions between VAX and IEEE are incorrect with OpenVMS V9.2-1. These problems are fixed in the OpenVMS V9.2-2 release. - Some of the run-time overflow checking has not been implemented yet. - 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 /SEPARATE_COMPILATION qualifier is currently ignored. A single Fortran source file is create a single object module. - The /MACHINE_CODE qualifier is ignored. As a workaround, you can use the ANALYZE/OBJECT/DISASSEMBLE to show the generated code and line numbers. 1.5 Features Missing From Documentation 1.5.1 New /ALIGN=COMMONS=PAD_ALIGN_SIZE Qualifier When the qualifier /ALIGN=COMMONS=MULTILANGUAGE is in effect, COMMON blocks within the compiled Fortran source are padded at the end of each such COMMON block in the same way that the C compiler would pad it, i.e. by a pad size based on the data types in the block. HP Fortran 95 previously contained an error (fixed in V7.6) which caused the padding to be based on the alignment specified in a directive. This error would cause a COMMON block that was aligned on an 8K boundary to also be padded out to an 8K size, for example. The new /ALIGN=COMMON=PAD_ALIGN_SIZE qualifier provides the previous padding behavior. 1.5.2 New /ASSUME=64BIT_STRING_PARAMS Qualifier By default, when a string variable is passed as an argument, it is passed with a 32-bit descriptor. When a 64-bit descriptor is desired (for example, when calling a routine written in another language using 64-bit descriptors), you need to individually designate each string variable for which you would like the 64-bit descriptor. 1-3 VSI FORTRAN V8.5-008 FOR OPENVMS X86-64 SYSTEMS RELEASE NOTES Some customers have requested an option to allow all such string variables used within a source file to be passed or received with 64-bit descriptors without needing to so specify for each individual string variable. The new [NO]64BIT_STRING_PARAMS keyword for the /ASSUME qualifier can be used to specify that requested behavior. When /ASSUME=64BIT_STRING_PARAMS is in effect, then all string variables used as parameters will be so used with 64-bit descriptors. NOTE This feature must be used with caution, as unexpected side effects may cause you problems. For example, because the Fortran Runtime Library expects to receive parameters with 32-bit addresses, statements that access the RTL either implicitly (e.g. print statements) or explicitly may fail when passed string parameters with 64-bit addresses. The default is /ASSUME=NO64BIT_STRING_PARAMS. 1.5.3 IA64, _IA64_ , X86, And _X86_64_ Predefine Symbols Are Implemented. 1.6 Floating-Point Arithmetic o IEEE is the default floating-point datatype (that is, the default is /FLOAT=IEEE_FLOAT) HP Fortran for OpenVMS Alpha Systems defaults to the VAX G_float floating-point format (/FLOAT=G_FLOAT). On OpenVMS I64 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. 1-4 VSI FORTRAN V8.5-008 FOR OPENVMS X86-64 SYSTEMS RELEASE NOTES 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. o 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). o 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 I64 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. o 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. 1-5 CHAPTER 2 VSI FORTRAN DOCUMENTATION AND ONLINE INFORMATION The VSI Fortran documentation set can be found online at https://docs.vmssoftware.com/ 2-1