Sun WorkShop Compiler FORTRAN 77 5 by huanghengdong


									Sun WorkShop Compiler FORTRAN 77 5.0      11/30/98

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.


            A.   New and Changed Features
            B.   Software Incompatibilities
            C.   Known Software Bugs
            D.   Fixed Software Bugs
            E.   Documentation Errata
            F.   Shippable Libraries

A. New and Changed Features

 f77 5.0 has the following features new or changed since 4.2:

     This release of the compiler can produce 64-bit object binaries on
     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

     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.

  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:       allocate memory
      CTIME64:        convert system clock to character string
      LTIME64:        convert system clock to array of local time units
      GMTIME64:       convert system clock fo array of GMT time units
      QSORT64:        sort elements of an array
         STAT64, LSTAT64, FSTAT64:   return file status
         FSEEKO64, FTELLO64:         get position/reposition file

    See the appropriate man pages (section 3F) for details.

     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
     can be used in an assigned GO TO or as a format identifier.

     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:
           REAL BETA(N,N)
     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.

     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.

  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         is an 8-byte integer constant with value 12
            12_4         is a 4-byte integer constant with value 12
    3123123123_8         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)

 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:

            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)

     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 "position-
     independent 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.
         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

         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.


         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.

         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:
      where is usually /opt.

B. Software Incompatibilities


       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 (,
          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 or
 The trailing -Bdynamic insures that all other libraries
          are implicitly linked dynamically, including system libraries

          In more complicated situations, link with the LD_OPTIONS environment
          variable set to '-Dfiles' to see which system library files are
          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:
           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

To top