nagfor — NAG Fortran Compiler Release 6.2
nagfor [mode] [option]... file...
nagfor is the interface to the NAG Fortran Compiler system. The compiler translates programs written in Fortran into executable programs, relocatable binary modules, assembler source files or C source files.
The mode determines the action performed, and can be one of
|=C||Compile (and/or link) C source files, acting as the companion processor; this passes options to the C compiler that are suitable for the ABI and/or compatibility mode options specified, and differs from the =compiler mode in that it does not set NAG-specific macro definitions or alter the #include file search path to include the compiler library directory.|
|=compiler||Compile (and/or link) the files; this is the default mode if none is specified.|
|=callgraph||Produce a callgraph of the Fortran routines in the files (see the Producing a Call Graph section).|
|=depend||Produce a dependency analysis of the Fortran files (see the Dependency Analysis section).|
|=epolish||Pretty-print (polish) the Fortran files using the Enhanced Polisher (see the Enhanced Source File Polishing section).|
|=interfaces||Produce a module or INCLUDE file containing procedure interfaces (see the Generating Interfaces section).|
|=polish||Pretty-print (polish) the Fortran files (see the Source File Polishing section).|
|=unifyprecision||Unify the precision of floating-point and complex entities in the files (see the Unifying Precision section).|
Options that do not apply to the current mode of operation (e.g. polish options when the mode is for compilation) are ignored.
A file ending in ‘.f90’ or ‘.f95’ is taken to be a Fortran free-form source file, a file ending in ‘.f’, ‘.for’ or ‘.ftn’ is taken to be a Fortran fixed-form source file; these assumptions can be overridden with the -fixed or -free option. A file ending in ‘.ff90’ or ‘.ff95’ is taken to be a free-form file requiring preprocessing by fpp, and a file ending in ‘.ff’ is taken to be a fixed-form file requiring preprocessing by fpp. A file ending in ‘.F90’ or ‘.F95’ is taken to be a free-form file requiring preprocessing by fpp, and a file ending in ‘.F’ is taken to be a fixed-form files requiring preprocessing by fpp.
If a filename without a suffix is provided nagfor will look for a file with the suffix ‘.f95’, and if that does not exist, the suffix ‘.f90’.
A file ending in ‘.c’ is taken to be a C source file. In the =compiler mode, this is assumed to be the output from the compiler with the -S option, and the C compiler is passed -D and -I options suitable for compiling such a file. In the =C mode, it is assumed to be a file for the companion processor; no -D is passed, and only -I options specified by the user. In both cases, options are passed to the C compiler according to the ABI and compatibility mode options.
Non-intrinsic modules, INCLUDE files and #include files are expected to exist in the current working directory or in a directory named by an -I option.
|ABI||Object size represented in||Character length represented in|
|-abi=64t||64 bits||32 bits|
|-abi=64c||64 bits||64 bits|
Programs compiled with -abi=32 will run on any x86 Linux system; those compiled with any 64-bit ABI will only run on a 64-bit kernel.
The default is -abi=64t. The -abi=64c option is compatible with the ABI used by Intel Fortran.
|alias||(check for assignments to aliased dummy arguments),|
|all||(perform all checks except for -C=undefined),|
|array||(check array bounds),|
|bits||(check bit intrinsic arguments),|
|calls||(check procedure references),|
|dangling||(check for dangling pointers),|
|do||(check DO loops for zero step values and|
|illicit modification of the index variable via host association),|
|intovf||(check for integer overflow),|
|none||(do no checking: this is the default),|
|present||(check OPTIONAL references),|
|pointer||(check POINTER references),|
|recursion||(check for invalid recursion) or|
|undefined||(check for undefined variables).|
The -C=alias option will produce a runtime error when it is detected that assignment to a dummy argument affects another dummy argument. At this release this is only detected for scalar dummy arguments.
The -C=dangling option will produce a runtime error when a dangling pointer is used; additionally, if the runtime option ‘show_dangling’ is set, a warning will be produced at the time the pointer becomes dangling (see Runtime Environment Variables for further information).
The -C=undefined option is subject to a number of limitations; in particular, it is not binary compatible with Fortran code compiled without that option, and is not compatible with calling C code via a BIND(C) interface. See the Undefined Variable Detection section for further details.
Colours are: black, red, green, yellow, blue, magenta, cyan and white.
would be a rather garish colour scheme.
|BIG_ENDIAN||synonym for BIG_IEEE|
|BIG_IEEE_DD||big-endian with IEEE floating-point, quad precision is double-double|
|BIG_IEEE||big-endian with IEEE floating-point, including quad precision|
|BIG_NATIVE||big-endian with native floating-point format|
|LITTLE_ENDIAN||synonym for LITTLE_IEEE|
|LITTLE_IEEE_DD||little-endian with IEEE floating-point, quad precision is double-double|
|LITTLE_IEEE||little-endian with IEEE floating-point, including quad precision|
|LITTLE_NATIVE||little-endian with native floating-point format|
|NATIVE||no conversion (the default)|
|Non-standard||Equivalent Standard Fortran Generic Intrinsic Function|
|DREAL(Z)||REAL(Z) or DBLE(Z)|
Runtime Error: Invalid input for real editing Program terminated by I/O error on unit 5 (Input_Unit,Formatted,Sequential) main.f90, line 28: Error occurred in READ_DATA main.f90, line 57: Called by READ_COORDS main.f90, line 40: Called by INITIAL main.f90, line 13: Called by $main$
This has no effect on default REAL and COMPLEX sizes, so the compiler is not standard-conforming in this mode.
In an indirect file, arguments may be given on separate lines; on a single line, multiple arguments may be separated by blanks. A blank can be included in an option or file name by putting the whole option or file name in quotes ("); this is the only quoting mechanism. An indirect file may reference other indirect files.
The -ieee option must be specified when compiling the main program unit, and its effect is global. The default mode is -ieee=stop. For more details see the IEEE 754 Arithmetic Support section.
For -kind=byte, the kind numbers for INTEGER, REAL and LOGICAL will match the number of bytes of storage (e.g., default REAL is 4 and DOUBLE PRECISION is 8). Note that COMPLEX kind numbers are the same as its REAL components, and thus half of the total byte length in the entity.
For -kind=sequential (the default), the kind numbers for all datatypes are numbered sequentially from 1, increasing with precision (e.g., default REAL is 1 and DOUBLE PRECISION is 2).
For -kind=unique, the kind numbers are unique across all data types, so that a kind number for one data type cannot be accidentally used for another data type (except that COMPLEX and REAL are still the same). These kind numbers are all greater than 100 so do not match byte sizes either.
This option does not affect the interpretation of byte-length specifiers (an extension to Fortran 77).
|all||(all options except for off),|
|line||(display file/line info if known),|
|off||(disable tracing output),|
|on||(enable tracing output),|
|paranoia||(protect memory allocator data structures against the user program),|
|size||(display size in bytes) or|
|verbose||(all options except for off and paranoia ).|
This option should be specified during both compilation and linking, and is incompatible with the -gc option. For more details see the Memory Tracing section.
Note that CHARACTER arrays are not affected by these options.
|c||(C source file),|
|fortran||(Fortran source file),|
|mod||(module information file),|
|none||(no output file),|
The -c, -F and -M options are equivalent to -otype=obj, -otype=Fortran and -otype=mod respectively.
This has no effect on INTEGER sizes, and so the compiler is not standard-conforming in this mode.
Note: This option has been superseded by the -double option which doubles the size of all numeric data types.
|i486, i586, i686, pentium2, pentium3, pentium4, prescott||the specified Intel processor,|
|k6, k6-2, k6-3, k6-4, athlon, athlon-4, athlon-xp, athlon-mp||the specified AMD processor,|
|pentium||(equivalent to i586) or|
|pentiumpro||(equivalent to i686).|
The default is to compile for pentium4 on Linux and MacOSX, and prescott on Windows.
For x86-64 (x86-compatible 64-bit mode compilation on Linux, MacOSX and Windows), machine may be either athlon64 or nocona.
Reallocation only occurs when the shape of an array, the value of a deferred type parameter, or the dynamic type (if polymorphic), differs between the variable (or subcomponent) and the expression (or the corresponding subcomponent). Allocation can occur also when the variable (or subcomponent) is not allocated prior to execution of the assignment (except for broadcast assignment). Note that -Warn=allocation thus subsumes -Warn=reallocation.
|/opt/NAG_Fortran/lib||Default NAG Fortran Compiler library directory on Sun Solaris (see -Qpath); referred to as library hereafter.|
|/usr/local/lib/NAG_Fortran||Default NAG Fortran Compiler library directory on other Unix-based operating systems.|
|C:\Program Files\NAG\EFBuilder 6.2\nagfor\lib||Default NAG Fortran Compiler library directory on 32-bit Windows.|
|C:\Program Files (x86)\NAG\EFBuilder 6.2\nagfor\lib||Default NAG Fortran Compiler library directory on 64-bit Windows.|
The messages produced by the NAG Fortran Compiler itself during compilation are intended to be self-explanatory. The linker, or more rarely the host C compiler, may produce occasional messages.
Messages produced by the compiler are classified by severity level; these levels are:
|Info||informational message, noting an aspect of the source code in which the user may be interested.|
|Warning||the source code appears likely to be in error.|
|Questionable||some questionable usage has been found in the source code which may indicate a programming error. This has the same severity as “warning”.|
|Extension||some non-standard-conforming source code has been detected but has successfully been compiled as an extension to the language. This has the same severity as “warning”.|
|Obsolescent||some archaic source code has been detected which although standard-conforming was classified as obsolescent by the Fortran standard (selected according to the -f95, -f2003 and -f2008 options). This has the same severity as “warning”.|
|Deleted feature used||a feature that was present in an older Fortran standard but deleted from the Fortran standard selected by a -fN option was used. This has the same severity as “warning”.|
|Error||the source code does not conform to the Fortran standard or does not make sense. Compilation continues after recovery.|
|Fatal||a serious error in the user's program from which the compiler cannot recover, the compilation is immediately terminated.|
|Panic||an internal inconsistency is found by one of the compiler's self-checks; this is a bug in the compiler itself and NAG should be notified.|
|Maximum INCLUDE file nesting||20|
|Maximum number of INCLUDE file references per compilation||2047|
|Maximum DATA-implied-DO loop nesting||99|
|Maximum array-constructor-implied-DO loop nesting||99|
|Maximum number of dummy arguments||32767|
|Maximum number of arguments to MIN and MAX||100|
|Maximum character length (except as below)||2147483647|
|Maximum character length (64-bit Windows and -abi=64c Linux)||1099511627775 (240-1)|
|Maximum array size (32-bit systems)||2147483647 bytes|
|Maximum array size (64-bit systems)||1 TiB|
|Maximum unit number||2147483647|
|Maximum input/output record length||2147483647 bytes|
|Standard error (stderr) unit number||0|
|Standard input (stdin) unit number||5|
|Standard output (stdout) unit number||6|
|Default maximum record length for formatted output||1024 characters|
|Default maximum record length for unformatted output||2147483647 bytes|
The default directory used for files opened with STATUS='SCRATCH' is ‘/tmp’ on Unix and the Windows temporary directory on Windows. This default may be overridden with the TMPDIR environment variable.
OpenMP 3.1 is supported.
When using the IEEE arithmetic support modules, the IEEE modes (rounding, halting and underflow) are propagated into spawned OpenMP threads at the beginning of a PARALLEL construct, and any IEEE flag that are set by an OpenMP thread is passed back to the parent thread at the end of the PARALLEL construct.
The following table lists the OpenMP environment variables with their default values and, if applicable, their limits.
|OMP_NUM_THREADS||number of cores||1-32768|
|OMP_DYNAMIC||False||true or false|
|OMP_NESTED||False||true or false|
|OMP_STACKSIZE||0||<1GB (32-bit) or 16GB (64-bit)|
|OMP_WAIT_POLICY||None||active or passive|
Note that although the NAG runtime supports up to 32768 threads, operating system limits may prevent usage of so many.
OpenMP is not compatible with the -C=undefined and -gline options.
All logical unit numbers are automatically preconnected to specific files. These files need not exist and will only be opened or created if they are accessed with READ or WRITE without an explicit OPEN. By default the specific filename for unit n is fort.n; however if the environment variable FORTnn exists its value is used as the filename. Note that there are two digits in this variable name, e.g. the variable controlling unit 1 is FORT01 whereas the default filename is ‘fort.1’ (unless the prefix has been changed, see the description of module F90_PRECONN_IO).
A file preconnected in this manner is opened with ACCESS='SEQUENTIAL'. If the initial READ or WRITE is an unformatted i/o statement, it is opened with FORM='UNFORMATTED' otherwise it is opened with FORM='FORMATTED'. By default a formatted connection is opened with BLANK='NULL' and POSITION='REWIND' (see module F90_PRECONN_IO).
Automatic preconnection applies only to the initial use of a logical unit; once CLOSEd the unit will not be reconnected automatically but must be explicitly OPENed.
Note that this facility means that it is possible for a READ or WRITE statement with an IOSTAT= clause to receive an i/o error code associated with the implicit OPEN.
If no floating-point option is specified, any floating divide-by-zero, overflow or invalid operand exception will cause the execution of the program to be terminated (with an informative message and usually a core dump). Occurrence of floating underflow may be reported on normal termination of the program. On hardware supporting IEEE 754 standard arithmetic gradual underflow with denormalised numbers will be enabled. Note that this mode of operation is the only one available on hardware which does not support IEEE 754.
If the -ieee=full option is specified, non-stop arithmetic is enabled; thus REAL variables may take on the values +Infinity, −Infinity and NaN (Not-a-Number). If any of the floating exceptions listed above are detected by the hardware during execution, this fact will be reported on normal termination. The -ieee=full option must be specified when compiling the main program and has global effect.
If the -ieee=nonstd option is specified, floating-point exceptions are handled in the default manner (i.e. execution is terminated). However, gradual underflow is not enabled, so results which would have produced a denormalised number produce zero instead. This option can only be used on hardware for which this mode of operation is faster. Like -ieee=full, the -ieee=nonstd option must be specified when compiling the main program and has global effect.
The random number generator supplied as the intrinsic subroutine RANDOM_NUMBER is the “Mersenne Twister”.
Note that this generator has a large state (630 32-bit integers) and an extremely long period (approx 106000), and therefore it is strongly recommended that the RANDOM_SEED routine only be used with a PUT argument that is the value returned by a previous call with GET; i.e., only to repeat a previous sequence. This is because if a user-specified seed has low entropy (likely since there are 630 values to be supplied), it is highly likely to set the generator to an apparently-low-entropy part of the sequence.
If you do want to provide your own seed (and thus entropy), you should store your values in the initial elements of the seed array and set all the remaining elements to zero — trailing zero elements will be ignored and not used to initialise the generator. Note that the seed is a random bitstream, and is therefore expected to have approximately half of its bits nonzero (thus providing many small integer values will likely result in a low-entropy part of the Mersenne Twister sequence being reached).
The -gc option enables use of the runtime garbage collector. It is necessary to use this option during the link phase for it to have effect; specifying it additionally during the compilation phase can result in improved performance.
The supplied Technical Information note (TECHINFO) lists whether garbage collection is available for your system. If it is available, there will be a file ‘gc.o’ in the compiler's library directory.
The collector used is based on version 5.3 of the publicly available general purpose garbage collecting storage allocator of Hans-J Boehm, Alan J Demers and Xerox Corporation, described in “Garbage Collection in an Uncooperative Environment” (H Boehm and M Weiser, Software Practice and Experience, September 1988, pp 807-820).
The copyright notice attached to their latest version is as follows:
Copyright 1988, 1989 Hans-J. Boehm, Alan J. Demers Copyright (c) 1991-1995 by Xerox Corporation. All rights reserved. Copyright 1996-1999 by Silicon Graphics. All rights reserved. Copyright 1999 by Hewlett-Packard Company. All rights reserved. THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED OR IMPLIED. ANY USE IS AT YOUR OWN RISK. Permission is hereby granted to use or copy this program for any purpose, provided the above notices are retained on all copies. Permission to modify the code and to distribute modified code is granted, provided the above notices are retained, and a notice that the code was modified is included with the above copyright notice.
Note that the “NO WARRANTY” disclaimer refers to the original copyright holders Boehm, Demers, Xerox Corporation, Silicon Graphics and Hewlett-Packard Company. The modified collector distributed in binary form with the NAG Fortran Compiler is subject to the same warranty and conditions as the rest of the NAG Fortran compilation system.
The module F90_GC is provided; it contains functions and variables that can control the behaviour of the garbage collector.
Tracing of memory allocation and deallocation is provided by the -mtrace option. Control is provided over whether the address, size, and line number of each allocation is displayed, or the tracing output can be suppressed entirely. A “paranoia” mode is provided where the memory allocator protects its data structures against inadvertent modification by the user program.
Runtime environment variables may be used to override the tracing options a program was built with, and to specify where to write the tracing output. These are only operative if the program was built with some tracing option; -mtrace=off will build a program with the tracing-capable memory allocator.
If -mtrace=off is not specified, use of any -mtrace option will implicitly do a -mtrace=on.
Basic tracing produces a message to the memory tracing file (normally standard error) for each allocation and deallocation, including those for automatic variables, i/o buffers and compiler-generated temporaries. Each allocation is numbered sequentially; the first three items are the i/o buffers for units 0, 5 and 6 (standard error, standard input and standard output).
All -mtrace= suboptions may be overridden at run time by the NAGFORTRAN_MTRACE_OPTIONS environment variable, which should be set to the required trace_opt_list (e.g. ‘on,size’). The memory tracing file may be specified at run time by the NAGFORTRAN_MTRACE_FILE environment variable.
The NAGFORTRAN_MTRACE_OPTIONS variable can also contain an option to limit the total amount of memory that may be allocated. The ‘limit=N’ option limits the maximum memory allocated to N MiB (mebibytes), but only if the program was built with a tracing option (minimally, -mtrace=off). Exceeding the memory limit will result in a normal “out of memory” condition, which if it occurs in an ALLOCATE statement, can be captured by a STAT= clause. Note that the memory limit applies to the overall memory usage including automatic variables and compiler-generated array temporaries.
The -mtrace option must be specified when linking, and is incompatible with -gc. Additionally, line number information is only available for those files compiled with -mtrace=line.
The nagfmcheck program can be used to check the output from the -mtrace option. It is designed to be used as a filter. Any lines that do not look like memory tracing output are ignored. It reports to standard output any errors it detects such as deallocating something twice, deallocating something that was never allocated, or deallocating something with a size different from that with which it was allocated. It also reports any apparent memory leaks, though this is less useful if the program terminated prematurely.
Use of undefined variables can be detected with the -C=undefined option. Program units compiled with this option use a different ABI, which means that they are incompatible with program units compiled without this option, and not interoperable with C; thus the whole program must be Fortran code and compiled the same way. For this reason, -C=undefined is not part of -C or -C=all.
Currently, there are a number of other limitations on the use of -C=undefined.
The table below lists the intrinsic data types provided by the NAG Fortran Compiler together with their kind numbers. There are three possible schemes for the intrinsic kind type parameters: the default mode of operation (which may be specified explicitly by the -kind=sequential option), the “byte” numbering scheme (specified by the -kind=byte option) and the “unique” numbering scheme (specified by the -kind=unique).
|Type||KIND Number||KIND Number||KIND Number||Name||Description|
|REAL||1||4||301||REAL32*||Single precision floating-point|
|REAL||2||8||302||REAL64*||Double precision floating-point|
|REAL||3||16||303||REAL128*||Quad precision floating-point|
|COMPLEX||1||4||301||REAL32*||Single precision complex|
|COMPLEX||2||8||302||REAL64*||Double precision complex|
|COMPLEX||3||16||303||REAL128*||Quadruple precision complex|
|LOGICAL||1||1||201||BYTE||Single byte logical|
|LOGICAL||2||2||202||TWOBYTE||Double byte logical|
|LOGICAL||4||8||204||LOGICAL64||Eight byte logical|
|INTEGER||3||4||103||INT32*||32-bit (default) integer|
|CHARACTER||1||1||646||ASCII||ASCII or ISO 8859-1 character|
|CHARACTER||2||2||213||JIS||JIS X 0213 character|
|CHARACTER||3||3||5323||UCS2||Unicode (UCS-2) character|
|CHARACTER||4||4||10646||UCS4||ISO 10646 (UCS-4) character|
The Name column of the table indicates the name provided by the intrinsic module F90_KIND; the ones marked * are also provided by the standard intrinsic module ISO_FORTRAN_ENV. Using these names avoids the portability problems that arise if the kind numbers are hard-coded.
Note that on all machines except Sun Solaris with the SunPro C compiler, quadruple precision is actually “double double” precision; this provides nearly twice the precision of Double precision but with a reduced exponent range.
To use a module it must be an intrinsic module, previously compiled, or defined in the file prior to its use. When separately compiling a module the -c option should be specified.
Compiling a module creates a ‘.mod’ file and a ‘.o’ file. The ‘.mod’ file is used by the compiler at compile time to provide information about module contents, the ‘.o’ file (if generated) contains the code of any module procedures and must be specified when creating an executable file.
Note that the name of the ‘.mod’ file will be the name of the module, the ‘.o’ file will be named after the original source file.
When a previously compiled module is USEd the NAG Fortran Compiler attempts to find its source file and, if that is successful, checks the modification times producing a warning message if the ‘.mod’ file is out of date.
The following variables control the runtime environment for programs compiled with the NAG Fortran Compiler.
|show_dangling||Enable tracing of dangling pointers; this only|
|affects code compiled with -C=dangling|
The show_dangling option causes messages to be produced on the runtime error file when a dangling pointer is created, reassociated with something else, nullified, or ceases to exist. For example,
[a.f90, line 20: Dangling pointer P detected (number 1), associated at b.f90, line 18] [c.f90, line 7: Dangling pointer P (number 1) has been reassociated] [c.f90, line 9: Dangling pointer Q (number 2) has been nullified] [file.f90, line 21: Dangling pointer R (number 3) no longer exists]The dangling pointer number is incremented every time a dangling pointer is detected. If an array with dangling pointer components ceases to exist, a message will be produced for each dangling pointer component of each element; however, the element subscripts will not be shown, instead ‘(...)’ will be produced to indicate that it is an array element, e.g.
[file.f90, line 44: Dangling pointer X(...)%A (number 8) no longer exists]
For operating systems other than Windows and MacOS a Modern Fortran-aware debugger might be available as dbx90; see TECHINFO.txt for details.
In general, host system debuggers, such as dbx or gdb, may be used successfully on Fortran code as the names of the original source files, plus line numbers, are passed through to the intermediate C files. In using such debuggers it should be noted that most local variables have an underscore appended to their names. It may be useful to look at the intermediate C code when debugging; this is produced by the -S option.
The call graph generator takes a set of Fortran source files and produces a call graph with optional index and called-by tables. C files and fpp-processed files are not handled.
The call graph generator understands the following compiler options with the same meaning: -132, -dcfuns, -double, -dryrun, -dusty, -encoding, -english, -f2003, -f2008, -f95, -fixed, -free, -help, -I, -i8, -indirect, -info, -kind, -max_parameter_size, -maxcontin, -mismatch, -mismatch_all, -nihongo, -nocheck_modtime, -nomod, -noqueue, -o, -openmp, -Qpath, -r8, -strict95, -thread_safe, -u, -u=sharing, -v, -V, -w and -xlicinfo.
The “@filename” syntax may also be used, with the same effect as the “-indirect filename” option.
The call graph is written to the file specified by the -o option, or to standard output if no -o option is specified.
The following additional options control the output produced.
The dependency analyser takes a set of Fortran source files and produces dependency information in the form specified. C files and fpp-processed files are not handled.
The dependency analyser understands the following compiler options with the same meaning: -132, -dryrun, -english, -fixed, -free, -help, -I, -indirect, -maxcontin, -nihongo, -o, -Qpath, -tempdir, -v and -V. The “@filename” syntax may also be used with the same effect as the “-indirect filename” option.
The following additional options control the operation of the dependency analyser:
|blist||(the filenames as an ordered build list),|
|dfile||(the dependencies in Makefile format, written to separate file.d files),|
|info||(the dependencies as English descriptions) or|
|make||(the dependencies in Makefile format).|
The default is -otype=info. If -otype=dfile is specified, no -o option is permitted; otherwise, the result is written to the file specified by the -o option or to standard output if no -o option is specified.
The interface generator takes a set of Fortran source files and produces interfaces for the procedures therein. The output is either a module (in a new source file), or an INCLUDE file.
The interfaces are written either to the file specified by the -o option, or if module output is being produced to the file with the same name as the module and extension ‘.f90’, or otherwise (an INCLUDE file is being produced) to ‘interfaces.inc’. In each case the interfaces are all within a single INTERFACE block.
The interface generator understands the following compiler options with the same meaning: -132, -dcfuns, -double, -dryrun, -dusty, -encoding, -english, -f2003, -f2008, -f95, -fixed, -free, -help, -I, -i8, -indirect, -info, -kind, -max_parameter_size, -maxcontin, -mismatch, -mismatch_all, -nihongo, -nocheck_modtime, -noqueue, -o, -openmp, -Qpath, -r8, -strict95, -tempdir, -thread_safe, -u, -u=sharing, -v, -V, -w and -xlicinfo.
The interface generator understands all the enhanced polish options with the same meaning.
The following additional options control the operation of the interface generator:
|module||(Fortran module in a new source file).|
The default is -otype=module.
The polisher takes a set of Fortran source files, which may be in fixed or free form, and produces a free form “polished” version of each file. C files and fpp-processed files are not handled.
The polisher understands the following compiler options with the same meaning: -132, -encoding, -english, -f2003, -f2008, -f95, -fixed, -free, -help, -I, -indirect, -info, -maxcontin, -nihongo, -noqueue, -o, -Qpath, -tempdir, -v, -V, -w and -xlicinfo.
The polished output is written to the file specified by the -o option, or to the same filename with the extension replaced by ‘.f90_pol’ if no -o option is specified. The output file cannot have the same name as the input file.
The following additional options control the operation of the polisher:
|Asis||(same as the input statement, but obey any -kind_keyword= option),|
|Keywords||(use LEN= and KIND=),|
|Kind_Keyword_Only||(use KIND= but not LEN=) or|
|No_Keywords||(use modern style with no keywords).|
The default is Asis; with any other style, the obsolescent “CHARACTER*length” form will be changed to the modern “CHARACTER(length)” form. When both the length and kind appear in the input statement, the length will appear first in the output statement.
The enhanced polisher takes a set of Fortran source files, which may be in fixed or free form, and produces a free form “polished” version of each file. C files and fpp-processed files are not handled. Unlike the simple polisher, the Fortran source files must be compilable without error; this is because the information needed for enhanced polishing requires successful semantic analysis of the files.
The enhanced polisher understands the following compiler options with the same meaning: -132, -abi, -dcfuns, -double, -dryrun, -dusty, -encoding, -english, -f2003, -f2008, -f95, -fixed, -free, -help, -I, -i8, -indirect, -info, -kind, -max_parameter_size, -maxcontin, -mismatch, -mismatch_all, -nihongo, -nocheck_modtime, -nomod, -noqueue, -o, -openmp, -Qpath, -r8, -strict95, -tempdir, -thread_safe, -u, -u=sharing, -v, -V, -w and -xlicinfo.
The enhanced polisher includes all the simple polish options, which are not repeated here.
Note that unlike nagfor =polish, -name_scopes=Asis acts as if it were -name_scopes=Keywords, which is the default. Similarly, -array_constructor_brackets=Asis acts as if it were -array_constructor_brackets=ParenSlash, and is the default, and -dcolon_in_decls=Asis acts as if it were -dcolon_in_decls=Insert, and is the default.
The default filename extension for the output file is ‘.f90_epo’, used when no -o option is specified.
The following additional options control the operation of this tool.
Keywords are not added to arguments that precede a label argument. The order of the arguments is unchanged.
This option is equivalent to -add_arg_keywords=all2,intrinsic3.
|all||(all classes of procedure),|
|bound||(object-bound and type-bound procedures),|
|intrinsic||(intrinsic procedures and intrinsic module procedures),|
|module||(non-intrinsic module procedures),|
|user||(procedures other than intrinsic procedures and intrinsic module procedures).|
Keywords are not added to arguments that precede a label argument. The order of the arguments is unchanged. Procedure pointer components are also known as “object-bound procedures”, and thus included in -add_arg_keywords=bound; named procedure pointers are treated as external procedures and thus included in -add_arg_keywords=external.
A suboption name may be followed by a single nonzero digit (e.g. “intrinsic3”); this specifies that for procedures covered by that suboption, keywords are only to be added if the procedure has at least that many dummy arguments. For type-bound and object-bound procedures, the passed-object dummy argument does not count towards the limit (as it never appears in the argument list). The intrinsic MAX and MIN functions use the number of actual arguments instead.
A suboption name followed by a digit may be further followed by the letter ‘a’ (e.g. “intrinsic3a”; this specifies that the argument limit applies to the number of actual arguments in a reference to the procedure, not the number of dummy arguments (the number of actual arguments will be less than the number of dummy arguments when an optional argument is omitted).
Note that suboptions are parsed from left to right, and later suboptions override earlier ones.
The precision unifier standardises floating-point and complex variable declarations, floating-point and complex literal constants, and some specific (non-generic) intrinsic procedures in a set of Fortran source files in order to unify the precision of these entities.
Standardisation to quadruple precision is only available on machines for which quadruple-precision floating-point arithmetic is available.
The tool attempts to make a standardising precision parameter accessible in program units (and interface blocks) via a use statement. You can control the form of this statement: the -pp_name= option controls the name of the precision parameter, and the -pp_module= option supplies the name of its host module (which is known as the ‘precision module’). The default form for the use statement (when no options are specified) is USE WORKING_PRECISION, ONLY: WP.
The -precision= option (whose default value is Double) can be supplied to set the desired unifying precision. The tool will use this setting when performing a number of checks of the validity of the standardisation process on the input files.
The precision module can be created by the tool, but otherwise does not itself undergo precision unification. A warning is issued if the tool encounters this module. A message is also emitted if no definition for the precision parameter is found in the module, or otherwise if the defined precision parameter specifies a different kind to the desired precision as provided or implied by the -precision= option.
The tool searches each program unit and interface block in the input source and determines whether the precision parameter is already accessible. If it is not, then a use statement, in the form given above, is inserted in the last allowable position for its statement type. For an internal or module procedure this statement is placed in the host. If the precision parameter is already declared in the form INTEGER, PARAMETER :: wp = constant_expression, then this declaration is deleted and a new use statement added, as previously described. (This PARAMETER form of statement is only recognised as declaring the precision parameter if it precedes all declarations of floating-point or complex entities in the scoping unit.) Any other form of definition or import of the precision parameter will not be modified, and the tool issues a warning that the standardised use statement could not be inserted.
Type declarations for floating-point and complex entities are standardised to include the precision parameter as kind parameter. Entities that are implicitly typed to be floating-point or complex are explicitly declared, in the same form. In the case when a function is defined with a floating-point or complex type specification on the function statement, this specification is deleted and a distinct type declaration statement for the function result is inserted into the function's declaration section.
Floating-point and complex literal constants are standardised to use the precision parameter as their kind.
The following specific procedure references are standardised to the generic replacement listed below:
(See also the description of -dcfuns.)
Furthermore, DBLE is converted to REAL. Following that, the KIND= argument is added to calls to REAL and CMPLX, when appropriate.
In cases where unifying the precision of the input source may lead in the generated output to undesirable side effects, or even invalid Fortran, the tool will attempt to issue a warning alerting you to the possibility. Here is a non-exhaustive list of situations where it may be inappropriate to apply this tool.
For procedures spread across several files clearly it is desirable to make sure this tool is applied to all files consistently. This will ensure, for example, that procedure references and the corresponding procedure definitions do not become inconsistent with respect to the type standardisation.
The precision unifier understands the following compiler options with the same meaning: -132, -abi, -dcfuns, -double, -dryrun, -dusty, -encoding, -english, -f2003, -f2008, -f95, -fixed, -free, -help, -I, -i8, -indirect, -info, -kind, -max_parameter_size, -maxcontin, -mismatch, -mismatch_all, -nihongo, -nocheck_modtime, -nomod, -noqueue, -o, -openmp, -Qpath, -r8, -strict95, -tempdir, -thread_safe, -u, -u=sharing, -v, -V, -w and -xlicinfo.
Note that using the -double or -r8 option affects the meaning of the -precision= option; see the description of the latter, below.
The standardised output is written to the file specified by the -o option, or to the same filename with the extension replaced by ‘.f90_prs’ if no -o option is specified. The output file cannot have the same name as the input file.
The precision unifier understands all the enhanced polish options with the same meaning.
The following additional options control the operation of this tool:
The created module will contain only the definition of the precision parameter, and unless the -nocmt_generation option is given, a comment identifying when the module was created.
Note that, since -double and -r8 double the size of default REAL (and possibly default DOUBLE PRECISION), specifying -double or -r8 will likewise modify the meaning of this -precision= option too.
Please check the web page http://www.nag.co.uk/doc/inun/np62/supplementary.html for details of any new information related to the applicability or usage of this product.
Please report any bugs found to ‘email@example.com’ or ‘firstname.lastname@example.org’, along with any suggestions for improvements.
Malcolm Cohen, Nihon Numerical Algorithms Group KK, Tokyo, Japan.