                   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. 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:

   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:      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.

   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:
              <digit-string>_<kind-digit>
     where <digit-string> is any string of decimal digits defining
     the constant, and <kind-digit> 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)
     

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

     -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 <n> = 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:
         <install_path>/SUNWspro/READMEs
      where <install_path> 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:
           <install_path>/SUNWspro/REAMDEs/runtime.libraries
        where <install_path> 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
