Sun WorkShop Compiler FORTRAN 77 5.0 11/30/98 _____________________________________________________________________________ _ INTRODUCTION: The Sun WorkShop Compiler FORTRAN 77 (f77) 5.0 runs on SPARC(TM) processors running Solaris(TM) SPARC Platform Edition, and Intel(R) x86 processors running Solaris Intel Platform Edition, versions 2.5.1, 2.6, and Solaris 7. CONTENTS: A. B. C. D. E. F. New and Changed Features Software Incompatibilities Known Software Bugs Fixed Software Bugs Documentation Errata Shippable Libraries ____________________________________________________________________________ A. New and Changed Features f77 5.0 has the following features new or changed since 4.2: o COMPILE FOR 64-BIT SOLARIS ENVIRONMENTS: This release of the compiler can produce 64-bit object binaries on either the 32-bit or 64-bit Solaris 7 SPARC Platform Edition. For the full story, see: * the f77(1) man page * the README file "64bit_Compilers" in /opt/SUNWspro/READMEs * the "Solaris 64-bit Developer's Guide" on AnswerBook2. Be aware that although a program is compiled for a 64-bit environment, the default data sizes for INTEGER, REAL, DOUBLE PRECISION, and COMPLEX do NOT automatically change. In many cases you may have to make explicit type declarations (INTEGER*8) and call special 64-bit library routines to take full advantage of the large file and large array support in 64-bit Solaris environment. See also the new -xtypemap= option for automatic promotion of certain default data types. o LARGE FILE SUPPORT: The f77 I/O library now supports large files on Solaris 2.6 and 7 (files larger than 2 Gigabytes). New user-callable library routines STAT64(3F), LSTAT64(3F), FSTAT64(3F), FSEEKO64(3F), and FTELLO64(3F) accept 64-bit integer status arrays and offset byte counts. These must be declared INTEGER*8. Note that the standard library routines FSTAT(3F), LSTAT(3F), and STAT(3F) do not return an error when called for status on a "large file", but only the lower 32 bits is returned in the STAT buffer for the total file size. FSEEK(3F) and FTELL(3F) will operate on large files in programs compiled for 64-bit environments (with -xarch=v9 on Solaris 7): with FSEEK, the offset input argument must be declared INTEGER*8; with FTELL, the function must be declared INTEGER*8. o LARGE ARRAYS (on 64-bit Solaris 7): In the 64-bit Solaris 7 environment (on SPARC V9 and UltraSPARC processors), memory addresses can be up to 64-bits wide, providing 4 billion times the current 4 gigabyte limit in a 32-bit environment. (Theoretically, that is; In practice, hardware restrictions on some platforms may limit the address space to less than the full 64 bits.) For Fortran this means that data arrays can be fully indexed by 8-byte integers (INTEGER*8) up to the limit of the particular platform. However, to prevent creation of extremely large object files, large arrays should not be initialized in DATA statements to anything but zeros. The intrinsic function LOC returns INTEGER*8 in 64-bit environments, and INTEGER*4 in 32-bit. In 64-bit environments, the variable receiving the result from LOC() must be declared POINTER or INTEGER*8. The instrinsic SIZEOF() returns INTEGER*4 in both 32-bit and 64-bit environments. To use SIZEOF() with arrays whose size in bytes is greater than the INTEGER*4 limit (2 Gb), the SIZEOF() function and the variables receiving the result must be declared INTEGER*8. Otherwise, the program will receive a truncated 32-bit result, with a warning. For example, in a 64-bit environment integer*8 xsize, SIZEOF ... xsize = SIZEOF(xarray) will work properly with an array greater than 2 Gb. Similarly, intrinsics LEN() and INDEX() must be declared INTEGER*8 when compiled for 64-bit environments and operating on very large character variables (larger than 2 Gbytes). Non-intrinsic library routines that reference large arrays or memory and their receiving variables must be declared INTEGER*8 when compiled for 64-bit environments. These include RINDEX(3F), LNBLNK(3F), SIGNAL(3F), TIME(3F), and MALLOC(3F). A new library routine, MALLOC64(3F), has been added. This routine always takes an INTEGER*8 argument (size of memory request in bytes) and always returns an INTEGER*8 value. Use this routine rather than MALLOC with programs that must run in both 32-bit and 64-bit environments. The receiving variable must be declared either POINTER or INTEGER*8. o NEW 64-BIT LIBRARY ROUTINES: This release introduces a number of new, 64-bit versions of some library routines. They are provided to improve portability of programs that must operate in both 32-bit and 64-bit (SPARC) environments. They include: MALLOC64: CTIME64: LTIME64: GMTIME64: QSORT64: allocate memory convert system clock to character string convert system clock to array of local time units convert system clock fo array of GMT time units sort elements of an array STAT64, LSTAT64, FSTAT64: FSEEKO64, FTELLO64: return file status get position/reposition file See the appropriate man pages (section 3F) for details. o OTHER LIBRARY/FUNCTION CHANGES FOR 64-BIT ENVIRONMENTS: Functions LONGJMP(env,val) and ISETJMP(env) require an INTEGER*8 array env(12) when compiling for 64-bit environments. To enable portability across 32-bit and 64-bit environments, always declare the env(12) array to be INTEGER*8 in both cases. o When compiled for a 64-bit platform environment (-xarch=v9), variables in an ASSIGN statement must be declared INTEGER*8. Also, the actual value stored by the ASSIGN statement is not available to the program, except by the assigned GO TO statement, or as a format identifier in an I/O statement. Only variables set by an ASSIGN statement can be used in an assigned GO TO or as a format identifier. o DYNAMIC ARRAYS: An dynamic array is an array that is local to a subprogram and not a dummy argument (or in a COMMON block) that is declared with a variable size (not a constant). For example: SUBROUTINE BLUE(A,N) REAL BETA(N,N) ... END Here the array BETA is a dynamic array. It is allocated when subroutine BLUE is invoked and deallocated when the subroutine returns. Consequently, dynamic arrays cannot appear on SAVE or DATA statements. o ARRAYS IN REDUCTION DIRECTIVE: With this release, arrays can now appear in the variables list of the REDUCTION directive. o YEAR 2000 SUPPORT: Library routines date(3F) and the VMS version of idate(3F) cannot be Year 2000 safe because they return 2-digit values for the year. See the man pages for date(3F), idate(3F) and a new routine, date_and_time(3F) for details. Use of unsafe date routines will generate warning messages at program start. o TASK COMMON: (SPARC only) The TASK COMMON directive in f77 gives the user the ability to declare private variables with an extended scope. This directive makes every variable declared in a task common block a private variable. Only named common blocks can be declared as task common. The syntax of the task common directive is: common /blockname/var,var,...,var C$PAR TASKCOMMON blockname The directive must appear immediately after the defining common declaration. This directive is effective only when compiled with flags -explicitpar or -parallel. Otherwise, the directive is ignored and the block is treated as a regular common block. Variables declared in task common blocks are treated as private variables in all the DOALL loops they appear directly or in the routines called from a loop where the specified common block is in scope. It is an error, detected at runtime, to declare a common block as task common in one compilation module and not in all others. This check for inconsistent common block declarations is disabled by default and can be enabled by compiling with -xcommonchk=yes. o FORTRAN 90-STYLE CONSTANTS: This release introduces a new syntax, borrowed from Fortran 90, for representing literal constants with a specific data size. This is a non-standard feature of Fortran 77. The format is: _ where is any string of decimal digits defining the constant, and is either 1, 2, 4, or 8, corresponding to the byte size of the data representation of the constant. For example: 12_8 12_4 3123123123_8 is an 8-byte integer constant with value 12 is a 4-byte integer constant with value 12 is an 8-byte integer constant too large to be represented as a 4-byte constant Where this is useful is in subprogram arguments, where constants of a particular data size are required: call dataz(X,12,1034_8) ... subroutine dataz(X,M,N) real X integer M integer*8 N ... Or, where you need to set an INTEGER*8 variable to a value outside the INTEGER*4 range, as in: integer*8 k ... k = 3 999 999 999 The constant will be truncated unless specified as a 64-bit constant: k = 3 999 999 999_8 For example, you must supply INTEGER*8 array length and element size when calling qsort64(3F): call qsort64(array,4000000000_8,8_8,condf) o OPTIMIZATION PRAGMA: The new optimization pragma (directive) allows the compiler's optimization level to be set at the subprogram level, overriding the level specified on the command line. For example, if the f77 command specifies -O4, all files listed on the command are compiled at this optimization level. However, if a subprogram contains the directive: C$PRAGMA SUN OPT=2 SUBROUTINE SMART(a,b,c,d,e,f) it will be compiled with optimization level 2 regardless of the -On specification on the f77 command. This directive must appear immediately before the target subprogram. A new f77 command line option flag, -xmaxopt, must also be specified for this pragma to be recognized. It is used to specify the maximum optimization level, and is described below. Note: If the source code containing this pragma is passed through the fpp(1) pre-processor, be sure that the letter "S" in "Sun" is capitalized. fpp(1) will see the lowercase "sun" as a variable and replace it with a value. o NEW OPTIONS: (See the f77(1) man page for details) -fpover[={yes|no}] With -fpover[=yes], the I/O library will trap floating-point overflow conditions that occur while processing input and return an error condition. The default is -fpover=no. -xarch=v9 -xarch=v9a (SPARC only) Causes compilation for V9 SPARC or UltraSPARC processors. Resulting object code can only be linked and executed on a 64-bit SPARC or UltraSPARC processor running Solaris 7. (Option only availble when compiling in the Solaris 7 environment.) -xcode=abs32|abs44|abs64|pic13|pic32 (SPARC only) Allows user to specify the memory address model for the compiled program. Available only on SPARC platforms. Enables compilation for 32-, 44-, or 64-bit absolute addresses, as well as the small and large "positionindependent code" models (equivalent to -pic and -PIC). -xcommonchk[={yes|no}] (SPARC only) By default, checking for inconsistent common/taskcommon declarations at run time is disabled. Compiling the program with -xcommonchk=yes enables runtime checking for common blocks declared task common in one source file but not in others. If a consistency is detected, the program will stop and an error message pointing at the first such inconsistency issued. The default is -xcommonchk=no To enable checking, all files must be compiled with -xcommonchk=yes. Note: This option is provided as a debugging aid; such runtime checks degrade performance and should only be enabled during program development. -xmaxopt[={5|1|2|3|4}] Enables the C$PRAGMA SUN OPT=n directive and controls the maximum optimization level. If a C$PRAGMA SUN OPT directive appears specifying a level greater than the level specified by the -xmaxopt flag, the optimization level used is the one specified by -xmaxopt. See discussion above regarding this new directive. The flag -xmaxopt by itself defaults to -xmaxopt=5 -xprefetch[={yes|no}] (SPARC only) Enables the compiler to generate prefetch instructions where appropriate on UltraSPARC II processors. Can be used when compiling with -xarch=v8plus, v8plusa, v9, and v9a (or any of the -xtarget platforms that include these -xarch values). -xvector[={yes|no}] (SPARC only) Enables the compiler to replace math library calls in DO loops with single calls to vector versions of the math routine where possible. o CHANGED OPTIONS -xcrossfile[={1|0}] This release adds an optional value = 0, or 1. The simple -xcrossfile of earlier releases is equivalent to -xcrossfile=1 and enables the compiler to perform optimizations such as inlining across all the source files specified on the f77 command. -xcrossfile=0 turns off cross file optimizations, and is the default. -Ztha The Thread Analyzer, tha, is not available with this release of Sun WorkShop. This option is now ignored. o SEE ALSO: The README file "math_libraries" contains latest information on optimized math functions, including versions for V9 SPARC platforms. The path to the README directory is: /SUNWspro/READMEs where is usually /opt. ____________________________________________________________________________ B. Software Incompatibilities Libraries If you compile with f77 5.0, you can link only with the 5.0 Sun libraries and not with earlier versions. Programs already compiled with f77 4.2, 4.0, or 3.0.1 can also link with the 5.0 libraries. Linking on SPARC V9 Processors under Solaris 7 Many static system libraries, such as libm.a and libc.a, are not available for SPARC V9 processors in the Solaris 7 environment. Only dynamic, shared libraries (libm.so, libc.so) are provided. This means that -Bstatic and -dn may cause linking errors on SPARC V9 Solaris 7 environments. Applications must use the dynamic libraries in these cases. To explicitly link with a static version of a user library, use a command line that looks something like: f77 -o prog prog.f -Bstatic -lxyz -labc -Bdynamic This will link with libxyz.a and libabc.a (rather than libxyz.so or libabc.so). The trailing -Bdynamic insures that all other libraries are implicitly linked dynamically, including system libraries libm.so and libc.so. In more complicated situations, link with the LD_OPTIONS environment variable set to '-Dfiles' to see which system library files are needed, and then use a link step that explicitly references each system and user library with -Bstatic or -Bdynamic. See the Fortran Programming guide for details. ____________________________________________________________________________ C. Known Software Deficiencies in this Release ____________________________________________________________________________ D. Fixed Software Bugs o -xprofile=collect|use now works the same on x86 platforms as described for SPARC platforms. ____________________________________________________________________________ E. Documentation Errata FORTRAN 77 Language Reference Manual (805-4939): o Dynamic arrays are not described. ____________________________________________________________________________ F. Shippable Libraries The README file "runtime.libraries" lists the Sun dynamic libraries that you may redistribute to other users as part of your license. This file can be found in: /SUNWspro/REAMDEs/runtime.libraries where is usually /opt in a standard installation. You may not redistribute or otherwise disclose the header files, source code, object modules, or static libraries of object modules in any form. The License to Use appears in the End User Object Code License, viewable from the back of the plastic case containing the CD ROM. ____________________________________________________________________________ Solaris, SunOS, and OpenWindows are trademarks or registered trademarks of Sun Microsystems, Inc. All SPARC trademarks, including the SCD Compliant Logo, are trademarks or registered trademarks of SPARC International, Inc. Intel is a registered trademark of Intel Corporation. Last Date Changed 98/11/30