Sun WorkShop Compiler Fortran 90 2

Document Sample
Sun WorkShop Compiler Fortran 90 2 Powered By Docstoc
					Sun WorkShop Compiler Fortran 90 2.0          12/14/98
__________________________________________________________________________

INTRODUCTION:

The Sun WorkShop Compiler Fortran 90 (f90) 2.0 runs on SPARC(TM) processors
under the Solaris(TM) Operating Environment, SPARC Platform Edition
versions 2.5.1, 2.6, and Solaris 7.

New and changed features since the 1.2 compiler are noted below.

________________________________________________________________________

Contents:

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

__________________________________________________________________________

A. New and Changed Features:


 f90 2.0 has the following features new or changed since 1.2:

   o COMPILE FOR 64-BIT SOLARIS 7:
     This release of the compiler can produce 64-bit object binaries on
     32-bit or 64-bit Solaris 7 SPARC Platform Edition.
     For the full story, see:
       * the f90(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, etc.) and call special
     64-bit library routines to take full advantage of the large file
     and large array support provided in the 64-bit Solaris environment.

  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.

     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.

     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),
     and MALLOC().

     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.

     One limitation for Fortran 90 programs in 64-bit environments is that
     the SIZE() intrinsic always returns default INTEGER, which remains
     INTEGER*4. This means that SIZE() cannot be used to determine the size
     of an array whose size is more than 2 Gb, unless the statement:
                INTEGER*8 SIZE
     also appears. (This may make the program technically no longer
     standard-conforming because SIZE() is an intrinsic.)

   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 a one-dimensional array
          STAT64, LSTAT64, FSTAT64: return file status
          FSEEKO64, FTELLO64:        get position/reposition file

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

   o LARGE FILE SUPPORT:
      On Solaris 2.6 and Solaris 7, the f90 I/O library now supports large
files
      (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.

     Large files written in the Solaris 2.6 or Solaris 7 environment cannot
     be read on earlier Solaris systems, such as 2.5.1.
o TASK COMMON:
  The TASK COMMON directive in f90 (and f77) enables the user 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

 When compiling with the -mp=cray flag (to accept Cray-style directives)
 the syntax expected is:

       CDIR$ 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 YEAR 2000 SUPPORT:
  Library routine date(3F) cannot be Year 2000 safe because it returns
  2-digit values for the year. See the man pages for date(3F),
  and date_and_time(3F) for details. Use of unsafe date
  routines will generate warning messages at program start.

o NEW OPTIONS:    (See the f90(1) man page for details)

 The following f77 options are newly introduced into f90:

 -a         -autopar     -C         -dalign     -depend
 -fsimple   -Kpic/KPIC   -libmil    -loopinfo   -O5
 -unroll    -xcg89/92    -xhelp=f   -pad/xpad   -xprofile
 -xvector   -xsb         -xs        -ztext

 The following options are new or have changed:

 -xarch=v9 -xarch=v9a
     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
      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}]
     By default, checking for inconsistent common/task common
     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.

 -xprefetch[={yes|no}]
     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}]
     Enables the compiler to replace math library calls in
     DO loops with single calls to vector versions of the
     math routine where possible.


o I/O DIFFERENCES:
   - NAMELIST output format:

      1.2: All variables in a single print statement written to a
           single line without line breaks.
      2.0: Each variable printed to a separate line.

      1.2: Comma used to separate values.
      2.0: Single blank separates values.

      1.2: Repeated values output using the r* form:
             3*8.22
      2.0: All repeated values output explicitly:
             8.22 8.22 8.22

      1.2: No trailing zero printing integer floating point:
               1.
      2.0: Floating point integers print with trailing zero:
               1.0

      1.2: Value printed may not be the same value when read in
           to a variable with the same type:
              0.1 when read in will print as 0.100000001
      2.0: Prints the minimum number of digits required to ensure
           that a value written produces the same value when read
        back in:      0.1 prints as 0.1

   1.2: As required by the standard, zero value prints in
        exponent form. But 1.2 prints 0.E+0
   2.0: Prints zero as 0.0E+0

   1.2: Prints a space between the comma and the imaginary part
        of a complex value:   (1., 0.E+0)
   2.0: No comma:             (1.0,0.0E+0)

- NAMELIST input:

   2.0: Allow the group name to be preceded by $ or & on input.
        The & is the only form accepted by the Fortran 90 standard,
        and is what is written by NAMELIST output.

   2.0: Accepts $ as the symbol terminating input except if the
        last data item in the group is CHARACTER, in which case
        it is treated as input data.

   2.0: Allows NAMELIST input to start in the first column of a
        record.

- PRINT * no longer comma-delimits output.

- OPEN FORM="BINARY" permits I/O of non-standard raw text
  without record marks:
   Opening a file with FORM='BINARY' has roughly the same
   effect as FORM='UNFORMATTED', except that no record
   lengths are embedded in the file. Without this data, there
   is no way to tell where one record begins, or ends.
   Thus, it is impossible to BACKSPACE a FORM='BINARY' file,
   because there is no way of telling where to backspace to.
   A READ on a 'BINARY' file will read as much data as needed
   to fill the variables on the input list.

- Recursive I/O possible on different units (this is because
  the f90 I/O library is "MT-Warm").

- The RECL= default record length on list directed and namelist
  output and direct I/O is now (2**31)-1.
  (The default was 267).

- ENCODE and DECODE are recognized and implemented as described
  in the FORTRAN 77 Language Reference Manual.

- Naming of scratch files is the same as with f77.

- Non-advancing I/O is enabled with ADVANCE='NO', as in:
        write(*,'(a)',ADVANCE='NO') 'n= '
        read(*,*) n

- Handling of I/O on internal files follows the Fortran 90
  standard more closely than was the case with f90 1.2.
  Also, calls to routines that do internal I/O are allowed on
  I/O lists. This was not allowed with 1.2 (or f77).
  - Runtime I/O errors are more verbose that in 1.2.
    For example:

         ***** FORTRAN RUN-TIME SYSTEM *****
         Error 1021: unformatted I/O on formatted unit
         Location: the READ statement at line 2 of "snarf.f"
         Abort (core dumped)

    To avoid error diagnostics from appearing, programs should handle
    their own error situations by using the ERR= clause on
    I/O statements. This is a good thing to do in general.

o OPERATIONAL DIFFERENCES:
   - f90 compiles "silently":
       Unlike the f77 compiler, f90 does not issue any "progress"
       messages during compilation, unless errors are detected.

  - Modules are handled differently:
      Compiling a source code that contains one or more MODULEs
      now causes an information file ( name.mod ) to be generated
      for each module. The name of this information file is the
      name of the module, in lowercase, with .mod suffix.
      A .mod file must be available before the module can be
      USEd. This means that all MODULE files must be compiled
      (and the module information files created) before compiling
      any file referencing a MODULE in a USE statement (unless
      the module is defined in the same file as, and above,
      the USE statement.)

    NOTE: The compatibility of .mod files is not guaranteed
      between subsequent releases of the f90 compiler.

  - The names of some of the libraries supplied with f90 have
    changed. These are listed in the f90(1) man page.

  - -ftrap=common is the default trapping mode.

  - -xhelp=readme will display this README file.

  - Routines from the Sun Performance Library are automatically
    linked to perform array operations.

  - The main program compiled by f90 2.0 is given the name "MAIN"
    and is called by a synthetic program called "main". When using
    dbx or the Sun WorkShop Debugger, you must specify the name of
    the main program as MAIN. This is particularly important in the
    dbx command:     stop in MAIN
    (With f90 1.2, the main program was called "main" and you would
    use the dbx command   stop in main .)

o LANGUAGE ELEMENTS:
   - Some Fortran 95 elements are implemented:
      The attributes PURE and ELEMENTAL
      The enhanced forms of MAXVAL and MINVAL

  - New data types are recognized:
        COMPLEX*16   REAL*16
              INTEGER *8   (also *1, *2)
              LOGICAL *8   (also *1, *2)

        - Some data representations have changed from f90 1.2:
              INTEGER*2 is now 2 bytes, not 4
              INTEGER*1 is now 1 byte, not 4
              LOGICAL*2 is now 2 bytes, not 4
              LOGICAL*1 is now 1 byte, not 4
           This will affect programs that read binary data files containing
these
           data items that were written with f90 programs compiled with the 1.2
           compiler. A workaround would be to change the declarations to be
           INTEGER*4 or LOGICAL*4 instead of *1 or *2 when compiling with 2.0.

        - Call by value, %VAL, is implemented in the same manner as f77.
          The only difference is that f90 2.0 allows REAL*8 and REAL*16
          to be passed to C routines as doubles and long doubles.

   o INTEROPERABILITY WITH f77 and C:
      - To mix f77 and f90 object binaries, link with the f77
        compatibility library, libf77compat, and not with libF77.
        For example, perform the link step with
            f90 ..files.. -lf77compat
        even if the main program is an f77 program.

        - The structure of f90 COMMON is now compatible with f77.

        - f90 scalar pointers are now compatible with ordinary C pointers.
          With f90 1.2, pointers were implemented as "pointer-to-pointer".
          This may require interfaces between C and Fortran 90 routines
          that pass pointers be changed.

   o DIRECTIVES:
      f90 2.0 recognizes the same directives as f77, except PRAGMA OPT=n.
      The Cray spellings (e.g. CDIR$ ) honored by f90 1.2 are now treated
      as comments by f90 2.0 unless you specify the -mp=cray compiler flag.

   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:

   o Features allowed in f77 but not in f90 are:

    - Names of variables starting with underscore (_) not allowed in f90.

    - Logical operators .ne. and .eq.      --   f90 requires .neq. and .eqv. with
      logical operands.

    - Implicitly recursive subroutines -- f90 requires explicit RECURSIVE
      keyword.
       - BYTE data type -- not recognized in f90.

   o Object binaries compiled with f90 1.2 are not compatible with
     the 2.0 compiler and will have to be recompiled.

__________________________________________________________________________

C. Known f90 Bugs:

   The following bugs are known and could not be fixed in time for this
   release. Check http://www.sun.com/workshop/users/ws.html for updated
   information about bugs, workarounds, and patches.

   o    -[x]pad=common is not supported.

   o    AUTOSCOPE qualifier is not honored on CMIC$ DOALL parallelization
        directives. A workaround is to rewrite all parallelization directives
        using Sun-style C$PAR DOALL directives, which does variable scoping
        automatically by default. (Sun-style directives, -mp=sun, is the
        default.)

   o    -fnonstd and -ftrap may not affect compile-time calculations.
        (4193571)

   o The ICHAR intrinsic can return negative values. A workaround is to
     add 256 to negative values to obtain the correct value. (4195990)

   o -Xlist does not analyze files with .F or .F90 suffix. (4193706)

   o The -C option (runtime array subscript checking) is not robust on
     64-bit platforms (compiling with -xarch=v9 on Solaris 7).

   o INTEGER *8 SHAPE intrinsic does not work properly with large arrays
     on 64-bit platforms. (4193397)

   o Internal functions that return string arrays can give wrong results.
     (4172909)

   o Calling a FORTRAN 77 subprogram from an f90 routine can fail when
     the f77 routine has statement labels as actual arguments. (4056526)

   o Cray pointers with value greater than 2**32 will print incorrectly
     on 64-bit platforms. A workaround is to save the pointer in an
     INTEGER*8 variable and print it. (4191730)

   o The expression      loc(A) - loc(B)  returns default integer rather
     than INTEGER*8 on 64-bit platforms. A workaround is to compute each
     address in its own variable:
             INTEGER*8 LA, LB, LDELTA
             ...
             LA = loc(A)
             LB = loc(B)
             LDELTA = LA - LB

   o dbx may fail to permit debugging of f90 main programs that do not begin
     with a PROGRAM statement, and contain internal subroutines.
     The error message issued by dbx is "No variant information available".
     The workaround is to add a PROGRAM statement to the main program.

   o Named constants defined by PARAMETER statements are not accessible to
     dbx. (4051860)

   o Initializing very large CHARACTER variables in a DATA statement may
     cause compiler errors. For example:

               character*25000 string
                   data string/' '/

     Increasing the amount of swap space available to the compiler with
     the swap(1M) SunOS command may fix the problem. (Increasing swap
     space and memory limits is described in the Fortran Programming Guide.)
     Recoding the example to perform the initialization at runtime would
     also avoid this problem.

   o AIMAG() returns incorrect result for complex component of derived type.
     For example:

             TYPE TEX
                 SEQUENCE
                 REAL A
                 REAL B
                 COMPLEX C
             END TYPE TEX

             TYPE(TEX) MEX
             MEX%A= 1
             MEX%B= 2
             MEX%C= (5.,6.)

             PRINT*, AIMAG(MEX%C)

     The wrong value for the imaginary part of MEX%C is printed.
     A workaround is to assign MEX%C to a temporary COMPLEX variable
     and take the AIMAG() of it.
__________________________________________________________________________

D. Fixed Software Bugs:

   o Many problems encountered with f90 1.2 (and pre-releases of 2.0)
     are fixed in this release of f90 2.0.

__________________________________________________________________________

E. Documentation Errata:


__________________________________________________________________________

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.



__________________________________________________________________________


f90 is derived from Cray CF90(tm), a product of Silicon Graphics, Inc.

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 12/14/98

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:12/18/2011
language:
pages:10