Digital_Fortran_____________________________________ Release Notes for OpenVMS Alpha Systems January 1997 This document contains information about new and changed features in this version of Digital Fortran for OpenVMS Alpha Systems. Software Version: Digital Fortran V7.1 Digital Equipment Corporation Maynard, Massachusetts ________________________________________________________________ January 1997 Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. © Digital Equipment Corporation 1997. All Rights Reserved. The following are trademarks of Digital Equipment Corporation: AlphaGeneration, AlphaStation, AlphaServer, Alpha AXP, AXP, Bookreader, DEC, DECnet, DECwindows, DEC Fortran, DIGITAL, OpenVMS, VAX, VAX FORTRAN, VMS, and the DIGITAL logo. PostScript is a trademark of Adobe Systems, Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. This document was prepared using VAX DOCUMENT Version 2.1. _________________________________________________________________ Contents 1 Digital Fortran Version V7.1 Overview 1.1 Operating system compatibility................ 1-1 1.2 The Digital Fortran Home Page................. 1-2 1.3 Getting Help and Reporting Problems........... 1-3 2 Digital Fortran New and Changed Features 2.1 New and Changed Features in V7.1.............. 2-1 2.1.1 Changes common to both Digital Fortran 90 and Digital Fortran 77.................... 2-1 2.1.1.1 FORRTL V7.1 or OpenVMS Alpha V7.1 Required................................ 2-1 2.1.1.2 /ARCHITECTURE Compile Command Qualifier............................... 2-2 2.1.1.3 New /OPTIMIZE=TUNE Keywords............. 2-3 2.1.1.4 Problem with NFS-mounted sources fixed................................... 2-3 2.1.2 Changes specific to Digital Fortran 90.... 2-3 2.1.2.1 Partial Fortran 95 support.............. 2-4 2.1.2.2 /PAD_SOURCE Qualifier Now Supported..... 2-5 2.1.2.3 Additional changes and corrections...... 2-5 2.1.3 Changes specific to Digital Fortran 77.... 2-8 2.1.3.1 G Format Edit Descriptor for Integer Variables............................... 2-8 2.1.3.2 DATE_AND_TIME Intrinsic................. 2-9 2.1.3.3 Use of POINTER Variables in DEBUG....... 2-9 2.1.3.4 Improved DEBUG support for PARAMETER constants............................... 2-10 2.1.3.5 Additional changes and corrections...... 2-11 2.1.3.6 Known problems in Digital Fortran 77.... 2-15 2.2 New and Changed Features in V7.0.............. 2-15 iii 2.2.1 Changes common to Digital Fortran 90 and Digital Fortran 77........................ 2-15 2.2.1.1 cDEC$ PSECT ALIGN= Keywords Supported... 2-15 2.2.1.2 DPROD Intrinsic Now Generic............. 2-15 2.2.1.3 /ASSUME=ACCURACY_SENSITIVE Changes...... 2-16 2.2.1.4 /ASSUME=BYTERECL Command Qualifier...... 2-16 2.2.1.5 /CHECK=NOPOWER Compile Command Keyword................................. 2-16 2.2.1.6 New /OPTIMIZE features.................. 2-17 2.2.1.7 /REENTRANCY Compile Command Qualifier... 2-17 2.2.1.8 Improvements in IEEE constant handling................................ 2-17 2.2.1.9 Improved optimizations.................. 2-18 2.2.1.10 Enhanced DEBUG support for optimized programs................................ 2-18 2.2.1.11 USEROPEN routines must be INTEGER....... 2-18 2.2.2 Changes specific to Digital Fortran 90.... 2-18 2.2.2.1 cDEC$ ALIAS directive now supported..... 2-19 2.2.2.2 cDEC$ ATTRIBUTES directive.............. 2-19 2.2.2.3 Variable Format Expressions in character literals now supported.................. 2-19 2.2.2.4 Abbreviations allowed in OPTIONS statement............................... 2-19 2.2.2.5 Enhanced support for the FORALL statement and construct................. 2-19 2.2.2.6 /NAMES qualifier now supported.......... 2-20 2.2.3 Changes specific to Digital Fortran 77.... 2-20 3 General information about Digital Fortran 3.1 Information common to Digital Fortran 90 and Digital Fortran 77............................ 3-1 3.1.1 OpenVMS 64-bit addressing................. 3-1 3.1.2 The Year 2000 Problem..................... 3-2 3.1.3 Optimizations on References to Dummy Arguments and COMMON...................... 3-3 3.1.4 Form of logical constants in formatted input..................................... 3-4 3.1.5 Control of Dynamic IEEE Rounding Modes.... 3-4 3.2 Information specific to Digital Fortran 90.... 3-4 3.2.1 Differences from Digital Fortran 77....... 3-4 3.2.2 Timezone support in DATE_AND_TIME intrinsic................................. 3-7 iv 3.2.3 cDEC$ ALIAS Directive..................... 3-7 3.2.4 The cDEC$ ATTRIBUTES Directive............ 3-9 4 Documentation Overview and Corrections 4.1 Digital Fortran Documentation and Online Information................................... 4-1 4.2 Digital Fortran Documentation Corrections..... 4-4 4.2.1 Digital Fortran Installation Guide for OpenVMS Systems........................... 4-4 4.2.2 DEC Fortran 90 User Manual for OpenVMS Alpha Systems............................. 4-4 4.2.3 DEC Fortran 90 Language Reference Manual.................................... 4-6 4.3 Online Readers Comments Form.................. 4-8 Tables 2-1 Pascal DEBUG Syntax for Fortran Pointee Expressions............................... 2-10 3-1 cDEC$ ATTRIBUTES Properties and Object Types..................................... 3-10 3-2 C Property and External Names............. 3-11 3-3 C Property and Argument Passing........... 3-12 v 1 _________________________________________________________________ Digital Fortran Version V7.1 Overview Digital Fortran Version V7.1 provides new versions of the Digital Fortran 90 and Digital Fortran 77 compilers which include new features as well as corrections to problems discovered in earlier versions. Digital Fortran Version V7.0 requires OpenVMS Alpha (formerly OpenVMS AXP) Version V6.1 or higher. The Digital Fortran product kit may be installed whether or not any earlier version of Digital Fortran, DEC Fortran or DEC Fortran 90 was previously installed. For complete installation details, see the Digital Fortran Installation Guide for OpenVMS Systems. This chapter provides general information about the Digital Fortran product. The remaining chapters provide the following information: o Chapter 2 highlights new and changed features in Digital Fortran. o Chapter 3 provides detailed information about Digital Fortran features not described in other documentation as well as general information on usage. o Chapter 4 lists the organization of the Digital Fortran documentation set and describes changes and corrections to the documentation. 1.1 Operating system compatibility Digital Fortran is supported on OpenVMS Alpha versions V6.1 through V7.1, the latest which has been released at the time of printing. It is likely that Digital Fortran will work correctly on all later versions of OpenVMS Alpha. If you have questions about version compatibility, please contact us as described in Section 1.3. Digital Fortran Version V7.1 Overview 1-1 Applications compiled with Digital Fortran version V7.0 require a compatible Fortran Run-Time Library, such as the one provided with the Digital Fortran kit. Applications to be run on other OpenVMS Alpha systems may require installation of the Run-Time Library kit as well, depending on which compiler is used, what features are used and what version of the operating system is installed. The following list provides details about version and feature compatibility. o Use of DECthreads to multi-thread a Fortran application using /REENTRANCY requires OpenVMS V7.0 or later. o Running Digital Fortran applications on OpenVMS versions earlier than V7.1 requires installation of the included Run-Time Library for proper operation. o OpenVMS versions earlier than V6.1 are not supported for running Digital Fortran applications. To install the Run-Time Library on other systems, use the POLYCENTER Software Installation (PCSI) FORRTL kit provided with Digital Fortran. This kit may be freely redistributed provided the terms specified in the Software Product Description (SPD) are honored. A copy of the Digital Fortran SPD can be found in the [.DOCUMENTATION] subdirectory of the Digital Fortran product directory on the Software Product Library CD-ROM. 1.2 The Digital Fortran Home Page If you have Internet access and a World Wide Web (WWW) viewer, you are welcome to view the following: o The Digital Fortran home page, located at the following URL: http://www.digital.com/info/hpc/fortran/ o The Digital Equipment Corporation home page, located at the following URL: http://www.digital.com/ 1-2 Digital Fortran Version V7.1 Overview 1.3 Getting Help and Reporting Problems If you encounter a problem while using Digital Fortran, report it to Digital. If an error occurs while Digital Fortran is in use and you believe the error is caused by a problem with Digital Fortran, take one of the following actions: o If you have a Software Product Services Support Agreement, consider contacting your Customer Support Center (CSC) by telephone (in the United States, 1-800- 354-9000) or by using the electronic means provided with your support agreement. You can use DSNlink or other electronic means to report the problem to the CSC. o Customers without a service contract can arrange for per-call CSC support. When you initially contact the CSC, please indicate the following: o The name and version number of the operating system (OpenVMS Alpha) you are using o The name (Digital Fortran 90 or Digital Fortran 77) and complete version number of the compiler you are using (The version number is displayed at the end of a compiler listing file) o The hardware system you are using (such as a model number) o How critical the problem is o A very brief description of the problem (one sentence if possible) When you submit information electronically or are speaking on the phone to the appropriate support specialist, you can provide more detailed information. This includes the specific commands used to compile and link the program, the error messages displayed, and relevant detailed information (possibly including source program listings). Please try to narrow the cause of the problem to a specific source module or lines of code. Digital Fortran Version V7.1 Overview 1-3 CSC personnel may ask for additional information, such as listings of any command files, INCLUDE files, relevant data files, and so forth. If the program is longer than 50 lines, submit a copy of it electronically or provide machine-readable media (floppy diskette or magnetic tape). Experience shows that problem reports sometimes do not contain enough information to duplicate or identify the problem. Concise, complete information helps Digital give accurate and timely service to software problems. To obtain information about purchasing Digital support services, please contact your local Digital sales representative. You may also send comments, questions and suggestions about the Digital Fortran product to the following Internet mail address: fortran@digital.com. Please note that this address is for informational inquiries and is not a formal support channel. 1-4 Digital Fortran Version V7.1 Overview 2 _________________________________________________________________ Digital Fortran New and Changed Features 2.1 New and Changed Features in V7.1 | | This section provides highlights of new and changed | features and problems corrected in Digital Fortran V7.1. | | | 2.1.1 Changes common to both Digital Fortran 90 and Digital | Fortran 77 | | The following changes are common to both Digital Fortran 90 | and Digital Fortran 77. | | 2.1.1.1 FORRTL V7.1 or OpenVMS Alpha V7.1 Required | | This version of Digital Fortran requires installation | of appropriate Fortran Run-Time Library support. This is | provided in OpenVMS Alpha V7.1 (released version only, not | "field test" versions) or by installing the accompanying | FORRTL kit as described in the Digital Fortran Installation | Guide for OpenVMS Systems. | The FORRTL V7.1 kit provides corrections to problems | discovered since the release of OpenVMS Alpha V7.0 and | adds support for the Fortran 90 NEAREST intrinsic. Digital | recommends that the FORRTL kit be installed on any system | running a version of OpenVMS Alpha earlier than V7.1 on | which Digital Fortran programs will be run. The FORRTL kit | may be redistributed according to the terms of the Digital | Fortran Software Product Description and is licensed under | the OpenVMS software license. | | | | Digital Fortran New and Changed Features 2-1 | 2.1.1.2 /ARCHITECTURE Compile Command Qualifier | | The new /ARCHITECTURE compile command qualifier determines | the type of Alpha processor code that will be generated | for this program. The /ARCHITECTURE option uses the same | keywords as the /OPTIMIZE=TUNE option. | | Whereas the /TUNE option is primarily used by certain | higher-level optimizations for instruction scheduling | purposes, the /ARCHITECTURE option determines the type | of code instructions generated for the program unit being | compiled. | | Digital OpenVMS Version 7.1 and subsequent releases | will 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 /ARCHITECTURE keywords are as follows: | | - 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. | | - 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. If HOST is | specified, the actual processor model code used is | displayed in the listing qualifier summary. | | - 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. 2-2 Digital Fortran New and Changed Features - EV5 generates code for some 21164 processor | 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. For the purposes of /ARCHITECTURE, the EV5 | keyword is equivalent to specifying EV4. | | - EV56 generates code for some 21164 processor | 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 OpenVMS Version 7.1 | (or later) systems. | | - PCA56 generates code for the 21164PC processor | 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 | OpenVMS Version 7.1 (or later) systems. | | 2.1.1.3 New /OPTIMIZE=TUNE Keywords | | The /OPTIMIZE=TUNE qualifier now accepts the EV56 and PCA56 | keywords. In addition, use of HOST will cause the processor | model used to be displayed in the listing qualifier | summary. | | 2.1.1.4 Problem with NFS-mounted sources fixed | | A problem was corrected in both compilers where the | compiler would fail to read a source file from an NFS- | mounted disk - the error message given was "RMS-F-COD, | invalid or unsupported type field in XAB ". | | 2.1.2 Changes specific to Digital Fortran 90 | | | Digital Fortran New and Changed Features 2-3 | 2.1.2.1 Partial Fortran 95 support | | This release includes a partial implementation of the | proposed Fortran 95 standard. The following features of the | proposed Fortran 95 standard have already been implemented | by previous versions of Digital Fortran 90: | | - FORALL statement and construct | | - Automatic deallocation of ALLOCATABLE arrays | | - Dim argument to MAXLOC and MINLOC | | The following features of the proposed Fortran 95 standard | have been implemented by this version of Digital Fortran | 90. See HELP F90 for information on most of these features. | | - Initial association status for pointers | | - Detection of Obsolescent and/or Deleted features listed | in the proposed Fortran 95 standard | | - Masked ELSEWHERE statement | | - Nested WHERE constructs | | - NULL Intrinsic | | - CPU_TIME intrinsic | | - Generic identifier in END Interface Statements | | - Kind argument to CEILING and FLOOR intriniscs | | - Pure user-defined subprograms | | - Automatic deallocation of ALLOCATABLE arrays | | - Implicit initialization of derived-type objects (static | case only) | | The compiler is capable of checking for syntax conformance | to either the Fortran 90 standard or the draft Fortran 95 | standard. The /STANDARD compile command qualifier has been | enhanced to optionally allow one of the following keywords: | | F90 - Check for conformance to Fortran 90 | F95 - Check for conformance to Fortran 95 | NONE - Do not check for standards conformance. | 2-4 Digital Fortran New and Changed Features The default is /NOSTANDARD which is the same as | /STANDARD=NONE. If /STANDARD is specified without a | keyword, the default is /STANDARD=F90. This default may | change to F95 in a future release. | | 2.1.2.2 /PAD_SOURCE Qualifier Now Supported | | Digital Fortran 90 now supports the /PAD_SOURCE qualifier | in the same manner as Digital Fortran 77. If /PAD_SOURCE is | specified, the compiler will implicitly pad with blanks any | fixed-form source records which are shorter than the source | width in effect (72 or 132 columns, dependent on /EXTEND_ | SOURCE.) The default is /NOPAD_SOURCE, for compatibility | with other Digital Fortran compilers. /PAD_SOURCE can | be used for compatibility with some non-Digital Fortran | compilers. This affects character constants which are | continued across multiple source records. | | 2.1.2.3 Additional changes and corrections | | The following additionalchanges and corrections are in this | version of Digital Fortran 90: | | o If /REAL_SIZE=64 or =128 is specified, and a real | constant includes an explicit kind specifier but no | exponent letter, the compiler no longer gives an error. | | o The compiler no longer fails if a derived type field is | named "fill". | | o The compiler now allows a source line to begin with a | semicolon in free-form. This is an extension to the | standard and is flagged as such. | | o The compiler now allows D-lines (/D_LINES) to be | continued. | | o The unformatted indexed REWRITE statement no longer | causes OUTSTAOVE errors when transmitting an aggregate. | | o BYTE or INTEGER*2 PARAMETER constants which are defined | using a constant value in the "unsigned" range are now | properly sign-extended when required. | | o The compiler no longer fails if two or more program | units in the same compiler invocation use the IARGCOUNT | intrinsic. | Digital Fortran New and Changed Features 2-5 | o The compiler now correctly treats a valueless OPEN | keyword (such as READONLY) as a keyword when it appears | at the start of the OPEN keyword list. | | o The compiler no longer gives incorrect errors when a | structure and record have the same name. | | o Compile-time evaluation of character intrinsics whose | arguments include a NUL character no longer produce | inconsistent results. | | o The NEAREST intrinsic function now returns correct | values for VAX floating types. This requires new math | library support which is provided in the accompanying | FORRTL kit or in OpenVMS Alpha V7.1. On OpenVMS versions | earlier than V7.1, calling the NEAREST intrinsic to | obtain the next higher value from HUGE() or the next | lower value from TINY() will result in an ACCVIO error | rather than the correct math library error reported. | This will be fixed in OpenVMS Alpha V7.1. | | o LOC(f90_pointer) no longer causes the compiler to fail. | | o The compiler no longer generates code in certain | cases involving a string array element argument to an | intrinsic routine, such as ADJUSTL. | | o The compiler no longer generates incorrect code for an | unformatted REWRITE of an array or record structure. | | o Compile-time integer overflows are now warnings rather | than errors. | | o The compiler no longer incorrectly merges rename lists | from a CONTAINed subprogram into those from the host | program unit. | | o Compiler had limited INCLUDE files to 20 per compilation | unit. There is no longer any fixed limit for the number | of INCLUDE files. INCLUDE nesting depth limit is 20. | | o Compiler limit of 99 continuation lines was raised to | 511. | | o Compiler did not completely honor OPTIONS /[NO]G_FLOAT. | | o Compiler abort with certain types of pointer assignment. | | o Incorrect error message for nested STRUCTUREs. 2-6 Digital Fortran New and Changed Features o Inconsistent severity for undeclared variable message | with IMPLICIT NONE or command line switch. | | o Incorrect error about passing LOGICAL*4 to a LOGICAL*1 | argument. | | o Lack of standards warning for non-integer expressions in | computed GOTO. | | o Incorrect flag NAME= as nonstandard in INQUIRE. | | o Lack of standards warning for AND, OR, XOR intrinsics. | | o VOLATILE attribute not honored for COMMON variables. | | o COMPLEX expression not allowed in variable format | expression. | | o Adjustable array not allowed to be declared AUTOMATIC | (AUTOMATIC declaration is ignored.) | | o /RECURSIVE not honored in main program. | | o Parsing error with DO-loop has bounds of -32768,32767. | | o Compiler abort when extending generic intrinsic. | | o SAVEd variable in inlined routine didn't always get | SAVEd. | | o Compiler abort with initialization of CHARACTER(LEN=0) | variable | | o Incorrect values of PRECISION, DIGITS, etc. for floating | types. | | o Incorrect value of INDEX with zero-length strings. | | o Incorrect value for SELECTED_REAL_KIND in PARAMETER | statement. | | o Incorrect compile-time result of VERIFY. | | o Routine using IARGPTR or IARGCOUNT corrupts address of | passed CHARACTER argument. | | o Lack of standards warning for CMPLX() in initialization | expression. | | o Compiler abort when %LOC(charvar) used in statement | function. | | o Incorrect initialization of STRUCTURE array. | Digital Fortran New and Changed Features 2-7 | o Compiler abort with large statement function. | | o RESHAPE of array with a zero bound aborts at runtime. | | o /INTEGER_SIZE not honored. | | o SIZEOF(SIZEOF()) should be 8. | | o Error parsing a derived type definition with a field | name starting with "FILL_". | | o With OPTIONS /NOI4, compiler complained of IAND with | arguments of an INTEGER*4 variable and a typeless | PARAMETER constant. | | o Incorrect standards warning for DABS. | | o Lack of Error message for ambiguous generic. | | o FOR$RAB was not always considered as returning an | INTEGER*4. | | o Error parsing field array reference in IF. | | o Bit constants in argument lists should be typed based on | value, not "default integer". | | o Compiler did not allow module to use itself. | | o Lack of standards warning for Hollerith constant. | | o Wrong values for TINY, HUGE for VAX floating. | | o EXPONENT() with /FLOAT=D_FLOAT references non-existent | math routine. | | 2.1.3 Changes specific to Digital Fortran 77 | | 2.1.3.1 G Format Edit Descriptor for Integer Variables | | If an integer variable is transmitted in formatted I/O | using a G format edit descriptor, Digital Fortran 77 | now adopts the Fortran 90 semantics of allowing this | combination and using an equivalent I format. In some | earlier releases, and on OpenVMS VAX, this combination | was disallowed and would result in a FORVARMIS error. Some | applications explicitly disabled this error (through ERRSET | on VAX and /CHECK=NOFORMAT on Alpha), where the behavior | would then be that the data was assumed to be REAL*4.) This | change in behavior may affect some applications which use | an integer variable in I/O to transmit data that may be | real. 2-8 Digital Fortran New and Changed Features 2.1.3.2 DATE_AND_TIME Intrinsic | | The DATE_AND_TIME intrinsic from the Fortran 90 standard | has been added to Digital Fortran 77 to provide a standard | interface for obtaining the date with a four-digit year | format. Use of this routine, in place of the non-standard | DATE or IDATE intrinsics, will allow an application to | function correctly in the year 2000 and beyond. | | The interface to DATE_AND_TIME is as follows: | | CALL DATE_AND_TIME ([date] ,[time] ,[zone] ,[values]) date | - CHARACTER*8 containing CCYYMMDD {CC is century} time | - CHARACTER*10 containing hhmmss.sss zone - CHARACTER*5 | containing ±hhmm {difference from UTC} values - INTEGER*4 | (8) array containing 4-digit year, month, day, zone, hour, | minutes, seconds, milliseconds | | Any of the arguments may be omitted, but any preceding | commas for omitted arguments must be specified. | | 2.1.3.3 Use of POINTER Variables in DEBUG | | Digital Fortran now correctly describes pointees, | declared in a POINTER statement, in the Debug Symbol | Table information for use with the OpenVMS Debugger. | However, the debugger does not contain full support for | pointer-type variables in Fortran. Scalar numeric pointees | can be examined by prefacing the pointee variable name | with the "@" character. For example, given the following | declarations: | | REAL X | POINTER (P,X) | | you could use the DEBUG command E @X to examine the | contents of X (pointed to by P). If the pointee has a | character, array or record type, however, the debugger | will not properly access the contents. Until the debugger | is enhanced in this area, a suitable workaround is to tell | the debugger that the language is Pascal, by means of a SET | LANGUAGE PASCAL DEBUG command, and use Pascal syntax, as | follows: | | o Place a caret "^" after the pointee variable name. | Digital Fortran New and Changed Features 2-9 | o Use square brackets "[]" instead of parentheses in | array and character references. | | As in Digital Fortran, a period is used as a record field | separator. Also, the debugger will properly use Fortran- | style column-major order array indexing even though the | language is set to Pascal. Note that the debugger does not | support COMPLEX constants in expressions, but can examine | COMPLEX variables. | | The following table shows equivalent Pascal syntax for | accessing various Fortran variable types. | | Table 2-1 Pascal DEBUG Syntax for Fortran Pointee | __________Expressions______________________________________ | | Fortran_Type____________________Pascal_DEBUG_Syntax________ | | Whole variable X X^ | | Character substring X(2:3) X^[2:3] | | Array reference X(2,3) X^[2,3] | | Field reference X.F X^.F | | Field_array_reference_X(3).F____X^[3].F____________________ | | OpenVMS Alpha V7.1 will contain Fortran DEBUG support for | pointer variables. | | 2.1.3.4 Improved DEBUG support for PARAMETER constants | | Digital Fortran 77 now supports /DEBUG=PARAMETER=NONE | | USED | ALL in the following manner: | | /DEBUG not present | | /DEBUG=(PARAMETERS=NONE,NOSYMBOLS,TRACEBACK) | /DEBUG alone | | /DEBUG=(PARAMETERS=USED,SYMBOLS,TRACEBACK) | /DEBUG=ALL | | /DEBUG=(PARAMETERS=ALL,SYMBOLS,TRACEBACK) 2-10 Digital Fortran New and Changed Features /DEBUG=NONE | | /DEBUG=(PARAMETERS=NONE,NOSYMBOLS,NOTRACEBACK) | | Note that the behavior for Digital Fortran 77 for OpenVMS Alpha | differs in two ways from that of Digital Fortran 77 for OpenVMS | VAX: | | /DEBUG=PARAMETER | | Alpha: /DEBUG=(PARAMETERS=ALL,NOSYMBOLS,TRACEBACK) | VAX: /DEBUG=(PARAMETERS=ALL,SYMBOLS,TRACEBACK) | /DEBUG=PARAM=USED | | Alpha: /DEBUG=(PARAMETERS=USED,NOSYMBOLS,TRACEBACK) | VAX: /DEBUG=(PARAMETERS=USED,SYMBOLS,TRACEBACK) | | In the OpenVMS VAX compiler, /DEBUG=PARAM is looked at | only if /DEBUG=SYMBOLS is set whereas the Alpha compiler | processes /DEBUG=PARAM independent of /DEBUG=SYMBOLS. | | 2.1.3.5 Additional changes and corrections | | The following changes and corrections are in this version | of Digital Fortran 77: | | ________________________ Note ________________________ | | /ASSUME=UNDERSCORE is available but as yet | undocumented in Digital Fortran 77. When set, | a trailing underscore {"_"} is appended to | external names (which is the default convention | for Digital Fortran 77 on Digital UNIX.) The | default is /ASSUME=NOUNDERSCORE. Users should use | /ASSUME=(ALL,NOUNDERSCORE) instead of /ASSUME=ALL if | they do not want this UNIX behavior. | | ______________________________________________________ | | o Deferred function argument expression can cause | problems, eg, "IF(F(I,(.NOT.X).AND.Y))THEN". | | o Be more tolerant of large typeless things like | SIZEOF(X'FFFFFFFFFFFFFFFFFFF'). | | o Do not delete adjustable array bounds that are | equivalenced into COMMON. | Digital Fortran New and Changed Features 2-11 | o Construct names can be a problem for .ANA files, | especially with no preceding real label. | | o Allow CHARACTER C*10(20) syntax in addition to CHARACTER | C(20)*10. | | o Fix large (INTEGER*8 sized) constant subscripts. | | o Fix F90 automatic and pointer arrays with variable | bounds. | | o Allow debugging with a pointer to an array in COMMON. | | o Allow $FORT T1.F/LIS,T2.F/NOLIS or $FORT T1.F/OBJ,T2.F | /NOOBJ. | | o Allow SIZEOF(CHARACTER_ARRAY(1)) - do runtime evaluation | if necessary. | | o Do NOT do .ANA file processing {eg, for USEROPEN} | without /ANA present. | | o Fix IBITS to not overflow on small integer types. | | o Fix (another) NAMELIST/SAVE/EQUIVALENCE problem. | | o Use less memory at compile-time for routine prolog code | for adjustably dimensioned arrays (a(n,n),b(n,n)). | | o Fix a.b.c offset computation. | | o "Small integer*1 op small integer*2 constant" should | give integer*1 result (ala VAX). | | o Change error message for YEAR2000 (suggest using DATE_ | AND_TIME, not DATE). | | o Data initialization incorrect for: "RECORD /S1/R1,/S2 | /R2" (r2 used s1 initialization). | | o Do not allow substrings to be merged in I/O lists | (N,STR(1:N) for example). | | o Fix a bug in nested uninitialized STRUCTUREs. | | o Allow CHARACTER *(*) C; PARAMETER (C='abcdefghijk') even | with /DEBUG=PARAM=ALL. | | o Better "function type" message string when mismatch | between caller and called function. | | o Give warning instead of assertion for REAL*4 X(10); | REAL*8 X. 2-12 Digital Fortran New and Changed Features o Fix IBITS on small integers so it doesn't overflow. | | o Do NOT allow VOLATILE to apply to a function name. | | o Fix illegal memory reference in compiler when the I/O | format is a CHARACTER function. | | o "CALL FOO(LEN(C))" with argument checking now gives | "Integer/Logical*8" for type instead of "Unknown". | | o Fix USEROPEN routine when using /ANA so a bad .ANA file | is not produced. | | o Implement multiple entry point functions with mixed | COMPLEX entry names. | | o Add /STAND=SEMANTICS warning of entry (of function) name | used before ENTRY statement. | | o Optimize the representation of field references. | | o Merge I/O lists with "simple" elements into a single I/O | call. | | o Implement /ARCHITECTURE = EV4 | EV5 | EV56 | PCA56 | | GENERIC | HOST. | | o An unused automatic data item no longer causes the | compiler to abort. | | o Code generation bugs were fixed in /OPTIMIZE=LOOPS and | /OPTIMIZE=LEVEL > 3. | | o .AND. and .OR. expressions in logical IFs now evaluate | left-to-right more often, find more short circuits, and | generate better code. | | o Allow dummy arguments to ENTRY statements to occur in | the declaration phase, eg: PARAMETER SX = SIZEOF (X) | where X only occurs as an ENTRY argument later. | | o Allow %VAL(expression) as the argument to LIB$ESTABLISH. | | o Make it easier for the debugger to find the start of a | routine. | | o Make CPPFILERR a warning {not an error} so that # 2000 | "xxx.F" is ignored when xxx.F is not present. | | o Put out better information for FUNCTION/ENTRY names for | debugging. | Digital Fortran New and Changed Features 2-13 | o Make ALTRETOMI an informational for return with | alternate label when no * in any dummy argument list. | | o Give better error message for bad character in octal/hex | constant. | | o Allow I/O keywords to be blank padded (for compile time | constants). | | o /INTEGER_SIZE= should affect constants in output | statements, e.g. TYPE *,1,2,3. This is an incompatible | change. | | o Allow continued DICTIONARY statement. | | o Let DICTIONARY definitions use their own /ALIGN setting | (instead of forcing /ALIGN=RECORD=PACKED). | | o Give informational (BRNCHINTOBLK) for jumping into block | or loop from outside: "Questionable branch into loop or | block". | | o Give an error (INVSUBUSE) when subroutine/entry names | are used as functions: "This name cannot be used as a | function reference". | | o Make it possible to pass CHARACTER*(*) function names | again. | | o Allow POINTER to functions/subroutines. | | o Fix the listing of /BY_REF_CALL to list more than the | first routine name. | | o Allow an optional ":" between CDEC$ TITLE | SUBTITLE and | the "[sub]title". | | o Add YEAR2000 warning for DATA/IDATE, suppressed by | /WARN=NOUSAGE : "Two-digit year return value may cause | problems with the year 2000". | | o Suppress BRNCHINTOBLK under /WARN=NOUSAGE. | | o Don't issue CHACONCONTD more than once per statement. | | o Fix variable lower bounds for second dimension so they | don't cause assertions. | | o Give error message (BADRANDU) for incorrect arguments to | RANDU: "Intrinsic RANDU arguments should be: (integer*2, | integer*2, real*4)" 2-14 Digital Fortran New and Changed Features o Catch adjutable array used as namelist element (avoid | internal error). | | o Code generation bugs were fixed in CHARACTER argument | setup, register reuse, loop reductions, and backwards | loops. | | 2.1.3.6 Known problems in Digital Fortran 77 | | o A bug in USEROPEN processing sometimes aborts the | compiler. The workaround is to compile with /ANALYSIS_ | DATA specified. | | 2.2 New and Changed Features in V7.0 This section provides highlights of new and changed features in Digital Fortran 7.0, as compared to the earlier separate products DEC Fortran 90 V2.0 and DEC Fortran V6.3. 2.2.1 Changes common to Digital Fortran 90 and Digital Fortran 77 2.2.1.1 cDEC$ PSECT ALIGN= Keywords Supported The cDEC$ PSECT ALIGN= specifier now supports the keywords BYTE, WORD, LONG, QUAD, OCTA and PAGE in addition to the integer constant expression previously allowed. These keywords are equivalent to the constants 0, 1, 2, 3, 4 and 16, respectively. This feature is also supported by version 6.4 of Digital Fortran for OpenVMS VAX Systems, where the keyword PAGE will be treated as if it were the constant 9 (the page size on OpenVMS VAX systems is 2**9 (512) bytes.) 2.2.1.2 DPROD Intrinsic Now Generic The DPROD intrinsic function has been extended to operate as a generic function which can accept arguments of types REAL*4 or REAL*8 (both arguments must be the same type.) If the arguments to DPROD are REAL*8, the function result is of type REAL*16. Note that if the DPROD intrinsic name is passed as an actual argument, the routine passed is the version with a REAL*8 function result. Digital Fortran New and Changed Features 2-15 2.2.1.3 /ASSUME=ACCURACY_SENSITIVE Changes The compilers have been changed so that the optimization resulting in calls to a special "reciprocal square root" routine for expressions of the form 1.0/SQRT(x) or A /SQRT(B) will be enabled only if /ASSUME=NOACCURACY_ SENSITIVE is in effect. The default is /ASSUME=ACCURACY_ SENSITIVE. Note that /FAST enables /ASSUME=NOACCURACY_ SENSITIVE. 2.2.1.4 /ASSUME=BYTERECL Command Qualifier Digital Fortran now supports the /ASSUME=BYTERECL qualifier on the command line. This controls the size of the unit used for the RECL= keyword in an OPEN or INQUIRE statement for unformatted files. The default, NOBYTERECL, specifies that RECL is in units of 4-byte longwords, compatible with current and past Digital Fortran products. If BYTERECL is specified, the unit for RECL is one byte, which is used on some non-Digital platforms. Use of the non-default BYTERECL value requires that the application be running on a system which has the associated Fortran Run-Time Library support. This support is provided by installing one of the following: Digital Fortran version V7.0 or later OpenVMS Alpha V7.0 or later If a program which specifies /ASSUME=BYTERECL is run on a system without the proper Run-Time Library support, it will fail with an INVARGFOR, Invalid argument to Fortran Run-Time Library error. 2.2.1.5 /CHECK=NOPOWER Compile Command Keyword By default, Digital Fortran follows the Fortran standard and disallows (gives a compile-time or run-time error) for real exponentiation of 0.0**0.0 or for a negative real number raised to an integer-valued power. Other languages and other Fortran implementations may allow these expressions. The /CHECK=NOPOWER compile command qualifier may be used to specify that Digital Fortran allow these expressions so that 0.0**0.0 gives a value of 1.0 and that negative real bases to raised integer-valued real powers are treated as if the exponent were integer valued (for example, -3.0**3.0 results in -27.0). 2-16 Digital Fortran New and Changed Features 2.2.1.6 New /OPTIMIZE features /OPTIMIZE=LEVEL=5 now enables a new set of loop transformation optimizations that apply to array references within loops, including: o Loop blocking o Loop distribution o Loop fusion o Loop interchange o Loop scalar replacement o Outer loop unrolling The loop transformations can be selectively disabled (as a group) by specifying /OPTIMIZE=NOTRANSFORM_LOOPS. Also, software pipelining, a set of optimizations previously enabled at optimization level 5, can be disabled using /OPTIMIZE=NOPIPELINE. 2.2.1.7 /REENTRANCY Compile Command Qualifier Digital Fortran now supports writing applications which use multithread or AST reentrancy during RTL calls. The new /REENTRANCY qualifier allows you to specify keyword values to indicate what type of reentrancy to support. (Use of this qualifier requires OpenVMS Alpha V7.0 or later - it is ignored if an application is run on earlier versions of OpenVMS Alpha). See the online HELP for further details. 2.2.1.8 Improvements in IEEE constant handling The compilers have improved handling of IEEE exceptional values (NaN, infinity) created during compile-time constant expression evaluation. If /FLOAT=IEEE is specified and a constant expression overflows or underflows or would result in a NaN, the correct exceptional value is used. This may result in run-time exceptions if the default /IEEE_MODE=FAST is in effect. Digital Fortran New and Changed Features 2-17 2.2.1.9 Improved optimizations To improve run-time performance, new optimizations are now available and certain improvements have been made, including: - Certain intrinsic procedures specific to Fortran 90 (not available in FORTRAN-77) - Subprogram calls with array arguments - New command-line qualifiers that activate new optimizations, including the loop transformation optimizations (/OPTIMIZE=LOOPS) or (/OPTIMIZE=LEVEL=5). The software pipelining optimization is now activated by using /OPTIMIZE=PIPELINE or /OPTIMIZE=LEVEL=5. 2.2.1.10 Enhanced DEBUG support for optimized programs Digital Fortran V7.0 contains enhanced support for debugging programs compiled with optimization as described in OpenVMS Version 7.0 New Features Manual. 2.2.1.11 USEROPEN routines must be INTEGER If a program specifies a USEROPEN routine in an OPEN statement and the routine is declared explicitly as some type other than INTEGER*4 or INTEGER*8, the compiler will now give a "Name previously used with conflicting data type" (INVTYPUSE) error. If the routine was not explicitly given a type, the compiler now assigns it the INTEGER*4 type, even if an IMPLICIT statement would specify a different type. However, if IMPLICIT NONE is in effect, and the type was not specified explicitly, then an IMPNONE error will be generated. Previously, the type conflict was not detected nor was a warning generated if IMPLICIT NONE was in effect. USEROPEN routines must return an INTEGER*4 or INTEGER*8 function value. 2.2.2 Changes specific to Digital Fortran 90 2-18 Digital Fortran New and Changed Features 2.2.2.1 cDEC$ ALIAS directive now supported The cDEC$ ALIAS directive is now supported in the same manner as in Digital Fortran 77. This directive provides the ability to specify that the external name of an external subprogram is different than the name by which it is referenced in the calling subprogram. For further details, see Section 3.2.3. 2.2.2.2 cDEC$ ATTRIBUTES directive The cDEC$ ATTRIBUTES directive lets you specify properties for data objects and procedures. These properties let you specify how data is passed and the rules for invoking procedures. This directive is intended to simplify mixed language calls with Digital Fortran routines written in C or Assembler. For more information on the cDEC$ ATTRIBUTES directive, see Section 3.2.4. 2.2.2.3 Variable Format Expressions in character literals now supported Simple forms of Variable Format Expressions (VFEs) are now allowed in character literal constant formats. The VFE may contain a single constant or variable name, but not an expression. VFEs in FORMAT statements may contain expressions. In addition, invalid Format strings in character literal constants are now detected at compile- time rather than at run-time. 2.2.2.4 Abbreviations allowed in OPTIONS statement The compiler now allows qualifier and keyword values in the OPTIONS statement to be abbreviated to the shortest unique value. 2.2.2.5 Enhanced support for the FORALL statement and construct The FORALL construct now allows the following statements in the forall body: - Pointer assignment statement - FORALL statement or construct (nested FORALL) - WHERE statement or construct Digital Fortran New and Changed Features 2-19 Please note that each statement in the FORALL body is executed completely before execution begins on the next FORALL body statement. The compiler now correctly defines the scope of a FORALL subscript name to be the scope of the FORALL construct. That is, the subscript name is valid only within the scope of the FORALL. Its value is undefined on completion of the FORALL construct. 2.2.2.6 /NAMES qualifier now supported The /NAMES qualifier, with keyword values of UPPERCASE, LOWERCASE and ASIS, is now supported in the same manner as in Digital Fortran 77. See the online HELP for further details. 2.2.3 Changes specific to Digital Fortran 77 The following additional changes are in this version of Digital Fortran 77: o CDEC$ OPTIONS /[NO]WARNINGS[=[NO]ALIGNMENT] The "CDEC$ OPTIONS" directive has been extended to accept /WARNINGS[=[NO]ALIGNMENT] /NOWARNINGS to turn off or on the local reporting of alignment warnings in STRUCTUREs or COMMONs. o The new directive CDEC$ RESTRICT pointee [, pointee]... CDEC$ RESTRICT * advises the compiler that objects pointed to using the POINTER statement are not accessed by any other name than the name in the POINTER statement {"pointee" above}. "*" means all such pointees are exclusively accessed by their pointee name. This allows for better optimizations of objects pointed to because the compiler can assume the only way to access the object is by its pointee name and no other. 2-20 Digital Fortran New and Changed Features o The following program shows a problem with Digital Fortran 77: PROGRAM X IMPLICIT NONE INTEGER*2 Y(ICHAR('A'):ICHAR('Z')) INTEGER*4 Z Z = ICHAR('A') END reports a compile-time error of "untyped name ICHAR" in the Y declaration. The work-around is to declare the intrinsic: INTEGER*4 ICHAR Digital Fortran New and Changed Features 2-21 3 _________________________________________________________________ General information about Digital Fortran This chapter provides general information applicable to Digital Fortran. 3.1 Information common to Digital Fortran 90 and Digital Fortran 77 3.1.1 OpenVMS 64-bit addressing OpenVMS Alpha version 7.0 introduces the ability to dynamically allocate data in "64-bit" address space. Digital Fortran does not formally support data in 64-bit address space, but some limited use of it may be made. To cause Fortran variables to be accessed in 64-bit space, the "CRAY POINTER" statement (not the Fortran 90 pointer attribute) must be used to associate a pointer value with a Fortran variable. Use the appropriate system services or the Run-Time Library routine LIB$GET_VM_64 to allocate data and store the address in the pointer variable. You may use the pointee variables in assignment statements and expressions and pass them as actual arguments. The following uses are known to not work for variables in 64- bit space: o I/O o Declaring the variable with CHARACTER type and passing it as an actual argument o Passing the variable by descriptor Mathematical intrinsic functions should work, but extensive testing has not yet been performed. There may be issues with Fortran 90 array operations. General information about Digital Fortran 3-1 Digital is interested in customer requirements for and experiences with use of dynamically allocated 64-bit space data in Fortran. Please send feedback to us by Internet mail at fortran@digital.com. For more information on OpenVMS support of 64-bit address space, see OpenVMS Alpha Guide to 64-Bit Addressing. 3.1.2 The Year 2000 Problem What is the Year 2000 Problem? It stems from the common practice of using two digits instead of four when writing dates and having multiple internal time formats. When this practice is extended into computer hardware and software, it causes arithmetic operations, comparisons, and data sorting procedures to yield incorrect results when working with years beyond 1999. As Digital's customers begin to consider the readiness of their computing systems for the transition to the year 2000, many have begun asking what impact it will have on their OpenVMS systems. We are happy to answer that, because of insightful development by the engineers who created it, OpenVMS was born ready. The OpenVMS operating system base date uses a 64-bit format that is totally unaffected by the transition to the year 2000. Customers who have consistently used the system base date and the associated system services that provide the ability to input and retrieve four digit ASCII year strings, will make a seamless transition into the year 2000 when accessing their data. The Digital Fortran compilers and their Run-Time Library are similarly unaffected by the transition to the year 2000. However, applications which use the DATE or IDATE intrinsic subroutines may need to be modified, as these routines return the year in a two-digit format. To determine if your application uses DATE or IDATE, specify the /MAP/FULL/CROSS qualifiers to the LINK command when linking your application. Then use the OpenVMS SEARCH utility or a text editor to search the resulting .MAP file for references to one of the following routines: DFOR$DATE_NUMERIC DFOR$DATE_T_DS 3-2 General information about Digital Fortran DFOR$IDATE DFOR$JDATE DFOR$KDATE The cross-reference section of the linker map will list the names of the application modules which reference these routines. Then examine the code which uses the routines to determine if modifications are necessary. For further information on the DATE and IDATE intrinsic subroutines, see the DEC Fortran 90 Language Reference Manual or DEC Fortran Language Reference Manual. As of version 7.0-42, Digital Fortran 77 issues an | informational diagnostic if DATE or IDATE is used in a | program. This diagnostic will be added to a future version | of Digital Fortran 90. | 3.1.3 Optimizations on References to Dummy Arguments and COMMON The Digital Fortran compiler can may make local copies of dummy arguments and/or variables in COMMON blocks for improved performance. The compiler is careful to always copy values back or fetch new values when the language semantics require it, but some applications may have taken advantage of other implementations' limitations in this area and may produce incorrect results. For dummy arguments, it is important to specify /ASSUME=DUMMY_ALIASES or to declare the variable as VOLATILE if a dummy argument can be addressed through some path other than the argument name; for example, if a dummy argument is also a COMMON variable, or if the routine can be called with some arguments omitted. By default, Digital Fortran assumes that the application conforms to the Fortran 90 and FORTRAN-77 standards in that it does not alias dummy arguments and that all actual arguments agree in order, number and data type (or structure, for record arguments), with their corresponding dummy arguments. See the appropriate Language Reference Manual for more information on the /ASSUME=DUMMY_ALIASES option. For variables in COMMON, it is important to name in a VOLATILE statement any variables or COMMON blocks that can be referenced (either read or written) other than by direct reference or during a routine call. For example, if a variable in COMMON is referenced in an OpenVMS AST General information about Digital Fortran 3-3 routine, condition handler or exit handler, or is in a shared global section, you must declare as VOLATILE that variable or the COMMON block to which it belongs. See the appropriate Language Reference Manual for more information on the VOLATILE statement. 3.1.4 Form of logical constants in formatted input Please note that in formatted, list-directed, and NAMELIST input of logical values, any string that starts with "F" is accepted as .FALSE. and any string that starts with "T" is accepted as .TRUE. 3.1.5 Control of Dynamic IEEE Rounding Modes The description of /ROUNDING_MODE=DYNAMIC is incorrect in saying that one can use the SYS$IEEE_SET_FP_CONTROL system service to control the dynamic rounding mode. Changing the dynamic rounding mode on OpenVMS requires use of an assembler routine at the present time. 3.2 Information specific to Digital Fortran 90 3.2.1 Differences from Digital Fortran 77 This section lists significant Digital Fortran 77 for OpenVMS Alpha features which are not implemented by Digital Fortran. For further details, please see Appendix A of the DEC Fortran 90 User Manual for OpenVMS Alpha Systems. The following FORTRAN command qualifiers and qualifier keywords are not supported by the F90 verb. o /ANALYSIS_DATA o /ASSUME=BACKSLASH o /CHECK=ASSERTIONS o /CROSS_REFERENCE o /DESIGN o /DML o /PAD_SOURCE o /SHOW=(DICTIONARY,PREPROCESSOR,SINGLE) 3-4 General information about Digital Fortran o /STANDARD=(MIA,SEMANTIC,SOURCE_FORM,SYNTAX) o /SYNTAX_ONLY o /TERMINAL o /WARNINGS=(TRUNCATED_SOURCE,UNREACHABLE,USAGE) The following Digital Fortran 77 language features are not supported by Digital Fortran. o DICTIONARY statement o Octal notation for integer constants ("0014) o Dummy arguments with nonconstant bounds in a NAMELIST group o The /NOF77 interpretation of the EXTERNAL statement o Extraneous parentheses in I/O lists The following semantic differences exist between Digital Fortran 90 and Digital Fortran 77 for OpenVMS Alpha Systems. o The Fortran-77 language specification did not define a default value for the BLANK= setting when reading from preconnected or internal files. For compatibility with VAX FORTRAN (and earlier Fortran-66 programs), Digital Fortran 77 for OpenVMS uses BLANK='ZERO'. The Fortran 90 language specifies that the default for internal files must be BLANK='NULL', therefore Digital Fortran 90 uses that setting, which is different from Digital Fortran 77 for OpenVMS. However, the Fortran 90 standard does not specify the BLANK= setting for preconnected files and Digital Fortran 90 for OpenVMS uses the same value, 'ZERO', as does Digital Fortran 77. (Note that if /NOVMS is specified, the default changes to BLANK='NULL' for both internal and preconnected files in both compilers.) o The Fortran-77 language did not allow a formatted READ to require more characters than were present in the external record. Digital Fortran 77 implements an extension called "short field termination" where if there are insufficient characters remaining in the record to satisfy a format edit descriptor's field width, that width is reduced to the number of remaining characters. General information about Digital Fortran 3-5 For example, consider the following program: READ (*,'(I5)') J WRITE (*,*) J END If the program was compiled with Digital Fortran 77 for OpenVMS and input was taken from an interactive terminal as follows: 123 Digital Fortran 77 would reduce the format field width from I5 to I3 and the program would display the value 123 for J. The Fortran 90 language added a new feature, the PAD= keyword to the OPEN statement, which specifies how short records are to be treated during formatted input. The default for all types of files is PAD='YES', which causes short records to be treated as if they were padded with blank characters to the required width. Because the Digital Fortran 90 for OpenVMS default is BLANK='ZERO' for preconnected files, the above example would display a value of 12300 for J; the blanks used for padding are treated as zeroes. This change in behavior may cause problems for some applications. To avoid problems in this area, Digital recommends adding an explicit BN format item to formats used for interactive I/O on preconnected units. | | If you have installed the Digital Fortran Run-Time | Library ECO FORRTLAVE01070 (or a later version of the | Run-Time Library), the Fortran 90 default for BLANK= is | changed to be 'NULL' for all types of files. This change | will also appear in a version of OpenVMS Alpha after | V7.0. For more information, see the release notes for | FORRTLAVE01070. Digital Fortran 90 enforces some additional language constraints which are not enforced by Digital Fortran 77. For example, a typed function may not be used in a CALL statement. This will cause problems for programs which declare OpenVMS system services and Run-Time Library routines as INTEGER*4 (or use the declaration modules in FORSYSDEF.TLB) but reference the functions in a CALL statement. To avoid this problem, make sure that typed 3-6 General information about Digital Fortran functions are referenced as functions and not by the CALL statement. For example: INTEGER*4 LIB$GET_VM . . . CALL LIB$GET_VM (100,POINTER) ! Wrong ISTAT = LIB$GET_VM (100,POINTER) ! Right For further information on language constraints, see Appendix A of the DEC Fortran 90 User Manual for OpenVMS Alpha Systems. 3.2.2 Timezone support in DATE_AND_TIME intrinsic The DATE_AND_TIME intrinsic has an optional parameter which returns the timezone differential from Coordinated Universal Time (UTC). By default, OpenVMS systems do not maintain information on timezone differential unless DECnet/OSI is installed or the system manager defines the timezone using the SYS$MANAGER:UTC$CONFIGURE_TDF.COM command procedure. If the timezone information is not available, the DATE_AND_TIME intrinsic will return a blank for the character ZONE argument and -1 for the differential element of the VALUES argument. If timezone information is desired, the system manager should define the timezone differential using either DECnet /OSI procedures or SYS$MANAGER:UTC$CONFIGURE_TDF.COM if DECnet/OSI is not installed. 3.2.3 cDEC$ ALIAS Directive The cDEC$ ALIAS directive is now supported in the same manner as in Digital Fortran 77. This directive provides the ability to specify that the external name of an external subprogram is different than the name by which it is referenced in the calling subprogram. The syntax is: cDEC$ ALIAS internal-name, external-name The internal-name is the name of the subprogram as used in the current program unit and external-name is either a quoted character constant or a symbolic name. General information about Digital Fortran 3-7 If external-name is a character constant, the value of that constant is used as the external name for the specified internal-name. The character constant is used as it appears, with no modifications for case or addition or removal of punctuation characters. The Digital Fortran 90 compiler will force the name into uppercase unless directed otherwise. If external-name is a symbolic name, the symbolic name (in upper case) is used as the external name for the specified internal-name. Any other declaration of the specified symbolic name is ignored for the purposes of the ALIAS directive. Note that the OpenVMS linker may have restrictions on what may appear in an external name and that upper and lower case in external names is significant. For example, in the following program (free source form): PROGRAM ALIAS_EXAMPLE !DEC$ ALIAS ROUT1, 'ROUT1A' !DEC$ ALIAS ROUT2, 'routine2_' !DEC$ ALIAS ROUT3, rout3A CALL ROUT1 CALL ROUT2 CALL ROUT3 END PROGRAM ALIAS_EXAMPLE The three calls would be to external routines named ROUT1A, routine2_, and ROUT3A. Because rout3A was not in quotation marks (character constant), its name was converted to uppercase. This feature can be useful when porting code between UNIX and OpenVMS systems where different routine naming conventions are in use. On UNIX systems, calling C functions from Fortran use the convention of using a lowercase routine name with a trailing underscore. If you wrote a C routine intended to be called from Fortran, you would have to name it in accordance to this convention. For example, ROUT2 would be coded in C as routine2_. If this application were ported to OpenVMS where routine names are not generally modified, the result would be that the linker would not resolve the reference to ROUT2 (aliased as routine2_), unless the cDEC$ ALIAS directive were removed. 3-8 General information about Digital Fortran By adding or removing the cDEC$ ALIAS directive, you can specify an alternate routine name without recoding the application. 3.2.4 The cDEC$ ATTRIBUTES Directive The cDEC$ ATTRIBUTES directive lets you specify properties for data objects and procedures. It takes the following form: cDEC$ ATTRIBUTES att [,att]... :: object [,object]... Where: c Is the letter or character (c, C, *, !) that introduces the directive (see your language reference manual). att Is one of the following: C ALIAS : external-name : internal-name REFERENCE VALUE object Is the name of a data object used as an argument or procedure. Table 3-1 shows valid combinations of properties with the various types of objects: General information about Digital Fortran 3-9 Table_3-1_cDEC$_ATTRIBUTES_Properties_and_Object_Types_____ __________________Object_Types__________________ Argument Common Subprogram Data Block Specification and Property___Declarations__Names[1]___EXTERNAL_Statements____ C Not allowed Allowed Allowed ALIAS Not allowed Not Allowed allowed REFERENCE Allowed Not Not allowed allowed VALUE Nonarrays Not Not allowed only allowed [1]Common_block_names_are_specified_as_[/]common-block-____ name[/]. ___________________________________________________________ For example, the C property can only be used with common block names and subprogram and EXTERNAL names, but not with variable declarations. The ALIAS property also applies to subprogram and EXTERNAL names (but not to other objects). In contrast, the REFERENCE and VALUE properties do not apply to subprogram and EXTERNAL procedure names (or common block names). They only apply to data declarations, but only REFERENCE (not VALUE) can be used for arrays or pointers to arrays. The cDEC$ ATTRIBUTES properties can be associated with function and subroutine definitions, in type declarations, and with the INTERFACE and ENTRY statements. Properties applied to entities available through use or host association are in effect during the association. For example (free source form): 3-10 General information about Digital Fortran MODULE MOD1 INTERFACE SUBROUTINE SUB1 !DEC$ ATTRIBUTES C :: SUB1 END SUBROUTINE END INTERFACE CONTAINS SUBROUTINE SUB2 CALL SUB1 END SUBROUTINE END MODULE In this case, the call to SUB1 within SUB2 uses the C property specified in the interface block. The properties are described as follows: o C This property lets you specify how data is to be passed when you use routines written in C or assembler with Fortran routines. When applied to a subprogram, the C property defines the subprogram as having a specific set of calling conventions. Note that Digital Fortran 90 on other platforms will apply the appropriate defaults and C rules for that platform. Table 3-2 summarizes the differences between the calling conventions: Table_3-2_C_Property_and_External_Names____________________ Fortran Item____________Default_________C_Property_Specified_______ Trailing No No underscore added to procedure names (continued on next page) General information about Digital Fortran 3-11 Table_3-2_(Cont.)_C_Property_and_External_Names____________ Fortran Item____________Default_________C_Property_Specified_______ Case of Uppercase, Uppercase, unless the ALIAS external unless the property is specified subprogram ALIAS property or /NAMES=ASIS or names is specified /NAMES=LOWERCASE is specified Argument See Table 3-3 See Table 3-3 passing____________________________________________________ In addition to the case of external names and the trailing underscore, the C property affects how arguments are passed, as described in Table 3-3. Table_3-3_C_Property_and_Argument_Passing__________________ Argument Variable C Property Specified Type__________________Fortran_Default__for_Routine_________ Scalar (includes Passed by Passed by value derived types) reference Scalar, with VALUE Passed by value Passed by value specified Scalar, with Passed by Passed by reference REFERENCE specified reference String Passed by String (1:1) padded descriptor to integer length String, with VALUE Error String (1:1) padded specified to integer length String, with Passed by Passed by reference REFERENCE specified reference Arrays, including Always passed Always passed by pointers_to_arrays____by_reference_____reference___________ If C is specified for a subprogram, arguments (except for arrays and characters) are passed by value. Subprograms using standard Fortran 90 conventions pass arguments by reference. 3-12 General information about Digital Fortran Character arguments are passed as follows: - By Fortran default, passed by class S or NCA (for arrays) descriptor. - If C is specified without VALUE or REFERENCE for the arguments, the first character of the string is passed (padded with zeros out to INTEGER*4 length). - If C is specified with REFERENCE for the argument (or if only REFERENCE is specified), the string is passed by reference. When the C property is specified, the case of the EXTERNAL name is forced to uppercase, even if /NAMES=ASIS or /NAMES=UPPERCASE was specified during compilation. To allow mixed case or lowercase names when the C property is specified, specify the ALIAS property for the same subprogram or EXTERNAL name. o ALIAS You can specify the ALIAS property as cDEC$ ALIAS or as cDEC$ ATTRIBUTES ALIAS; both are equivalent. The ALIAS property provides the ability to specify that the external name of an external subprogram is different than the name by which it is referenced in the calling subprogram (see Section 3.2.3). When both ALIAS and C properties are used for a subprogram or EXTERNAL name, the ALIAS property takes precedence over the C property. This allows you to specify case-sensitive names (the C attribute sets them to lowercase). o REFERENCE and VALUE These properties specify how a dummy argument is to be passed. REFERENCE specifies a dummy argument's memory location is to be passed instead of the argument's value. VALUE specifies a dummy argument's value is to be passed instead of the argument's memory location. When a dummy argument has the VALUE property, the actual argument passed to it can be of a different type. If necessary, type conversion is performed before the subprogram is called. General information about Digital Fortran 3-13 Character values, substrings, assumed-size arrays, and adjustable arrays cannot be passed by value. When REFERENCE is specified for a character argument, the string is passed with no length. VALUE is the default if the C property is specified in the subprogram definition. Consider the following free-form example which declares a routine that accepts an integer argument by value: interface subroutine foo (a) !DEC$ ATTRIBUTES C :: foo integer a end subroutine foo end interface This subroutine can be invoked from Fortran using the name foo (no underscore): integer i i = 1 call foo(i) end program The actual subroutine code: subroutine foo (i) !DEC$ ATTRIBUTES C :: foo integer i i = i + 1 . . end subroutine foo 3-14 General information about Digital Fortran 4 _________________________________________________________________ Documentation Overview and Corrections The sections in this chapter: o Describe Digital Fortran documentation and online information (Section 4.1) o List known Digital Fortran documentation corrections (Section 4.2) o Describes how you can send comments about Digital Fortran documentation and online information to Digital (Section 4.3) 4.1 Digital Fortran Documentation and Online Information The Digital Fortran documentation set includes the following: o Digital Fortran Installation Guide for OpenVMS Alpha Systems (AA-PU3AD-TE) Explains how to install Digital Fortran on an OpenVMS Alpha operating system, including requirements. The installation guide is included with the Digital Fortran document kit, QA-MV1AA-GZ.7.n. It is also included in ASCII and PostScript[TM] form on the Software Product Library CD-ROM and is on the Online Documentation Library CD-ROM in Bookreader form. o DEC Fortran 90 Language Reference Manual (AA-Q66SB-TK) Describes the Digital Fortran 90 source language for reference purposes, including the format and use of statements, intrinsic procedures, and other language elements. It also provides an overview of new Fortran 90 features (not available in FORTRAN-77). Documentation Overview and Corrections 4-1 It identifies extensions to the Fortran 90 standard by blue color in the printed document and by shading in Bookreader. When using Bookreader Version 4.0, note that the shading of extensions may be inaccurate. This document is included with the Digital Fortran document kit, QA-MV1AA-GZ.7.n and is on the Online Documentation Library CD-ROM in Bookreader form. o DEC Fortran 90 User Manual for OpenVMS Alpha Systems (AA-QJRWA-TE) Describes the Digital Fortran program development and run-time environment on OpenVMS Alpha systems. It describes compiling, linking, running, and debugging Digital Fortran 90 programs, performance guidelines, run-time I/O and error-handling support, data types, numeric data conversion, calling other procedures, and compatibility with Digital Fortran 77. This document is included with the Digital Fortran document kit, QA-MV1AA-GZ.7.n and is on the Online Documentation Library CD-ROM in Bookreader form. o DEC Fortran Language Reference Manual (AA-PU45B-TK) Describes the Digital Fortran 77 source language for reference purposes, including the format and use of statements, intrinsic procedures, and other language elements. It identifies extensions to the Fortran 77 standard by blue color in the printed document and by shading in Bookreader. When using Bookreader Version 4.0, note that the shading of extensions may be inaccurate. This document is included with the Digital Fortran 77 document kit, QA-MV1AB-GZ.7.n and is on the Online Documentation Library CD-ROM in Bookreader form. o DEC Fortran User Manual for OpenVMS AXP Systems (AA- PU39A-TE) Describes the Digital Fortran 77 program development and run-time environment on OpenVMS Alpha systems. It describes compiling, linking, running, and debugging Digital Fortran 77 programs, performance guidelines, run-time I/O and error-handling support, data types, 4-2 Documentation Overview and Corrections numeric data conversion, calling other procedures, and compatibility with Digital Fortran on other platforms. This document is included with the Digital Fortran 77 document kit, QA-MV1AB-GZ.7.n and is on the Online Documentation Library CD-ROM in Bookreader form. o Read Before Installing or Using Digital Fortran Version 7.0 for OpenVMS Alpha Systems (AV-PU3BF-TE) This cover letter contains information about installing Digital Fortran that may not be included in the installation guide or in the release notes. This cover letter is included with the Digital Fortran document kit, QA-2ASAA-GZ.2.n. It is also included on the Software Product Library CD-ROM in ASCII and PostScript form. The Digital Fortran Software Product Description (SPD) is provided on the Software Product Library CD-ROM. The following Digital Fortran online information is available (once installed on the system): o Digital Fortran online release notes Provide more information on this version of Digital Fortran, including known problems. To display or print the Digital Fortran release notes before installing, use the PRODUCT EXTRACT RELEASE_NOTES FORTRAN command (see the Digital Fortran Installation Guide for OpenVMS Alpha Systems). Once installed, the ASCII version of the online release notes are located in: SYS$HELP:FORTRAN.RELEASE_NOTES Other forms of the release notes (PostScript and Bookreader) are also provided, using the file name: SYS$HELP:FORTRAN_RELEASE_NOTES.* o Digital Fortran online help The Digital Fortran HELP module in SYS$HELP:HELPLIB.HLB provides online access to Digital Fortran 90 and Digital Fortran 77 help, including descriptions of F90 command qualifiers, a summary of the language elements Documentation Overview and Corrections 4-3 (statements, intrinsic procedures, and so on), error message descriptions, and other information. To view the online Digital Fortran help file using the HELP command, type: $ HELP F90 for Digital Fortran 90, or: $ HELP FORTRAN for Digital Fortran 77. You can specify topics to navigate the help hierarchy. For example: $ HELP F90 /ALIGN The Digital Fortran Installation Guide for OpenVMS Alpha Systems, the "read first" cover letter, and the SPD are available on the OpenVMS Alpha Software Product Library CD-ROM in ASCII and PostScript format. All Digital Fortran documents except the cover letter, SPD, and these release notes are available on the Online Documentation Library CD-ROM in Bookreader format. 4.2 Digital Fortran Documentation Corrections This section contains information that does not appear in the Digital Fortran documentation. 4.2.1 Digital Fortran Installation Guide for OpenVMS Systems No known corrections apply to the this guide, order number AA-PU3AD-TE (April 1996 on the inside title page). 4.2.2 DEC Fortran 90 User Manual for OpenVMS Alpha Systems The following correction applies to order number AA-QJRWA- TE (April 1995 on the inside title page): o References to F90$FORSYSDEF.TLB should be replaced with FORSYSDEF.TLB. Starting with Digital Fortran Version 7.0, the F90$FORSYSDEF.TLB library name is no longer used (both Digital Fortran 90 and Digital Fortran 77 use FORSYSDEF.TLB). 4-4 Documentation Overview and Corrections o References to DEC Fortran 90 Installation Guide for OpenVMS Alpha Systems should be replaced with the Version 7.0 title, Digital Fortran Installation Guide for OpenVMS Alpha Systems. o In Section 2.3.4, under the description of /ASSUME=[NO]SOURCE_INCLUDE (page 2-31), it incorrectly states that SOURCE_INCLUDE applies to modules files as well as include files and include text libraries. For Digital Fortran 90 Version V7.1-330, the /ASSUME=[NO]SOURCE_INCLUDE qualifier does not apply to module files. o Page 2-75, Example 2-1: Add (M,N) after the COMMON X statement. o Pages 2-76 to 2-77, Example 2-2 and Example 2-3: The listing formats have changed slightly, especially with regard to generated code, label use, and program sections. Compiler-generated labels appear as L$n or lab$000n. o Page 4-4, first paragraph on the page: Replace the first paragraph with the following (a newer OpenVMS debugger interface is now available): "The DECwindows interface provides a main window in which portions are updated as the program executes, including the source code, typed commands, and debugger messages. This interface provides pull-down menus and uses the kept debugger (equivalent of DEBUG/KEEP)." o Page 5-12, Example 5-1: in the last DO loop, the reference to FOO should be BOO. o Pages 10-48 to 10-49, Section 10.8.7: The first paragraph incorrectly states that MGN expects arguments by value and HLN by reference. The reverse is true (HLN expects arguments by value and MGN by reference). In addition, the online Bookreader version and the printed DEC Fortran 90 User Manual for OpenVMS Alpha Systems do not describe new command-line features, enhancements to the language, and other changes since Version 2.0. For information on new features and related information, see Chapter 2. Documentation Overview and Corrections 4-5 4.2.3 DEC Fortran 90 Language Reference Manual The following corrections apply to order number AA-Q66TB-TK (April 1995 on the inside title page): o In Chapter 5, the syntax incorrectly shows that a comma is not needed between a data type and an attribute. For example, in Section 5.2: type [attr-list,] ALLOCATABLE [,attr-list] :: array[(d- spec)] [,array[(d-spec)]]... The correct syntax has comma between type and [attr- list,]. Examples in Chapter 5 correctly show a comma between a data type and an attribute. For example: REAL, ALLOCATABLE :: Z(:, :, :) The correct syntax follows: type, [attr-list,] ALLOCATABLE [,attr-list] :: array[(d- spec)] [,array[(d-spec)]]... type, [attr-list,] AUTOMATIC [,attr-list] :: v [,v]... type, [attr-list,] STATIC [,attr-list] :: v [,v]... type, [attr-list,] DIMENSION (a-spec) [,attr-list] :: array[(a-spec)] [,array[(a-spec)]]... type, [attr-list,] EXTERNAL [,attr-list] :: ex-pro [,ex- pro]... type, [attr-list,] INTENT (intent-spec) [,attr-list] :: d-arg [, d-arg]... type, [attr-list,] INTRINSIC [,attr-list] :: in-pro [,in-pro]... type, [attr-list,] OPTIONAL [,attr-list] :: d-arg [,d- arg]... type, [attr-list,] PARAMETER [,attr-list] :: c = expr[, c = expr]... type, [attr-list,] POINTER [,attr-list] :: pointer [(d- spec)] [,pointer [(d-spec)]]... type, [attr-list,] PRIVATE [,attr-list] :: entity [,entity]... type, [attr-list,] PUBLIC [,attr-list] :: entity [,entity]... 4-6 Documentation Overview and Corrections type, [attr-list,] SAVE [,attr-list] :: [object [,object]...] type, [attr-list,] TARGET [,attr-list] :: object [(a- spec)] [,object [(a-spec)]]... type, [attr-list,] VOLATILE [,attr-list] :: object [,object]... New language features added since Version 2.0 are not provided in the DEC Fortran 90 Language Reference Manual. For information on new language features, see Chapter 2. Documentation Overview and Corrections 4-7 4.3 Online Readers Comments Form Use the following online form as a template for sending comments about Digital Fortran documentation by Internet mail, FAX, or postal service. --------------------------------------------------------------------- Please complete this survey and send an online version (via Internet) or a hardcopy version (via FAX or postal service) to: Internet mail: fortran_docs@zko.mts.dec.com FAX: 603-881-0120 Attn: Languages Documentation, ZKO2-3/K35 Postal service: Digital Equipment Corporation, Languages Documentation, ZK02-3/K35 110 Spit Brook Road, Nashua, N.H. 03062-2698 USA Manual Title: ________________________________ Order Number: _________________ Fortran Version: ________________ _____________________________________________________________________ We welcome any comments on this manual or any Digital Fortran manual. 1. If you found any errors, please list them: Page Description ____ ___________________________________________________________ ____ ___________________________________________________________ 2. How can we improve the content, usability, or otherwise improve our documentation set? _________________________________________________________________ _________________________________________________________________ Your Name/Title ______________________________ Dept. _________ Company ________________________________________ Date _________ Electronic address or FAX number _________________________________ Mailing Address ________________________________________________ __________________________________________ Phone ______________ 4-8 Documentation Overview and Corrections