                                                              Updated 2002/05/02

 Forte[tm] Developer 7: Fortran 95 Readme

     Contents

       A. Introduction
       B. About the Forte Developer 7 Release
       C. New and Changed Features
       D. Software Corrections
       E. Problems and Workarounds
       F. Limitations and Incompatibilities
       G. Documentation Errors
       H. Required Patches for Fortran 95
       I. Shippable Libraries



     ------------------------------------------------------------------

     A. Introduction

     This document contains information about the Forte[tm] Developer 7
     Fortran 95 compiler, f95. This document describes the new features
     and software corrections that are introduced by this release, and
     lists known problems, limitations, and incompatibilities.
     Information in this document updates and extends information in
     the software manuals.

     Information in the release notes overrides information in all
     readme files. To access the release notes and the complete Forte
     Developer documentation set, go to the documentation index at
     file:/opt/SUNWspro/docs/index.html.

     To view the text version of this readme, type the following at a
     command prompt:

        f95 -xhelp=readme

     To view the HTML version of this readme, go to:

        file:/opt/SUNWspro/docs/index.html

     Note - If your Forte Developer 7 software is not installed in the
     /opt directory, ask your system administrator for the equivalent
     path on your system.



     ------------------------------------------------------------------

     B. About Forte Developer 7 Fortran 95

     This release of Fortran 95 is available on the Solaris[tm]
     operating environment (SPARC[tm] Platform Edition) versions 7, 8,
     and 9.



     ------------------------------------------------------------------

     C. New and Changed Features

     This section describes new and changed features for this release
     of Fortran 95.

       1. Fortran 77 Compatibility Flag
       2. -use Option
       3. Enhanced MODULE Features
       4. -Xlist Enhancements
       5. Identify Known Libraries
       6. Ignoring Dummy Argument Type in Interfaces
       7. -xalias for Optimizing With Aliasing
       8. Enhancements to -C Runtime Checking
       9. The BYTE Data Type
      10. Fortran 2000 Features
      11. Rounding in Formatted I/O
      12. Obsolete Flags Removed
      13. Check for Stack Overflow
      14. New Default Thread Stack Size
      15. Enhanced Interprocedural Optimizations
      16. Prefetch Level

     For details, see the f95(1) man page.

       1. Fortran 77 Compatibility Flag

          This release of the Fortran 95 compiler introduces a Fortran
          77 compatibility mode, enabled with the -f77 flag. In
          compatibility mode, the compiler accepts many Fortran 77
          constructs that are normally incompatible with Fortran 95.
          There is no Fortran 77 compiler (f77) in this Forte Developer
          7 release. An f77 script has been provided to call the f95
          compiler with the appropriate arguments. See the f77(1) man
          page for details.

          The -f77 flag accepts a comma-separated list of keywords for
          selecting various compatibility features: f95 -f77=list. All
          compatibility features are selected if the flag appears
          without a feature list: f95 -f77

          The compatibility features include:
             o ensuring similar formatted, list-directed, and namelist
               output
             o allowing the same input formats as Fortran 77
             o handling tab-formatting and unlimited input line lengths
             o accepting backslash escape sequences in strings
             o handling Fortran 77 logical data and expressions
             o allowing non-integer subscripting
             o recognize only Fortran 77 intrinsics
             o plus many miscellaneous Fortran 77 extensions.

          But note the following:
             o When linking with object files compiled by previous
               releases of the f77 compiler, you will need to also
               specify -xlang=f77 to link with the correct Fortran 77
               support libraries.
             o To match Fortran 77's behavior regarding arithmetic
               exceptions, add -ftrap=%none to the command line. If
               -fast also appears, put the -ftrap=%none after-fast
               because -fast will set the trapping mode to common.

          The Fortran User's Guide Chapter 5 lists the known
          compatibility and incompatibility issues between f95 and f77.
          The Fortran Library Reference details the FORTRAN 77 and VMS
          FORTRAN intrinsic functions supported by f95.

       2. -use Option

          The new -use=list flag forces one or more implicit USE
          statements into each subprogram or module subprogram compiled
          with this flag. This means it is not necessary to modify
          source programs when a module or module file is required for
          some feature of a library or application.

          Compiling with -use=module_name has the effect of adding a
          USE module_name to each subprogram or module being compiled.
          Compiling with -use=module-file-name has the effect of adding
          a USE module-name for each of the modules contained in the
          module-file-name file.

          The argument is a comma-separated list of module names or
          module file names. Symbols defined by explicit USE statements
          take precedence over implicit definitions from -use modules.

          For the compiler to differentiate a module name from a module
          file name, the argument must include a path, even a trivial
          path such as ./mymodulefile.mod

       3. Enhanced MODULE Features

             o A new option flag, -moddir=directory_name, and
               environment variable, MODDIR, control where f95 writes
               compiled MODULE subprograms (.mod files). Otherwise, the
               compiler writes .mod files in the current directory.

             o The -M flag will now accept an archive (.a) file or
               module (.mod) file as an argument, as well as a
               directory name. The compiler determines the type of the
               file by examining its contents -- the actual file
               extension is ignored.

             o The way the compiler searches for modules has also
               changed in this release:

                  + An archive file must be explicitly specified with a
                    -M flag for it to be searched for modules. The
                    compiler will not search archive files by default.

                  + Only .mod files with the same names that appear on
                    USE statements will be searched. For example,
                    USE ME causes the compiler to only look for the
                    module file me.mod by default. In previous
                    releases, the compiler would look in all archive
                    and module files it found.

                  + When searching for modules, the compiler gives
                    higher priority to the directory where the module
                    files are being written. This is controlled by the
                    -moddir option and MODDIR environment variable.
                    When neither are specified, the default
                    write-directory is the current directory.

                    This means that if only the -M option appears, the
                    current directory will be searched first for
                    modules before the directories and files listed on
                    the -M option. To emulate the behavior of previous
                    releases, use:

                    -moddir=empty-dir -Mdir -M.

                    where empty-dir is a directory that contains no
                    module files.

             o The way the compiler records module and include file
               dependences in Makefiles with the .KEEP_STATE target has
               also improved. See the make(1) man page for details on
               using .KEEP_STATE.

       4. -Xlist Enhancements

          Global program analysis with the -Xlist flag has been
          enhanced with a number of new checks.

          Suboption -XlistMP provides a new domain of global program
          analysis -- verification of OpenMP directives.

       5. Identify Known Libraries

          A new option flag, -xknown_lib=keywords, directs the compiler
          to treat references to certain known libraries as intrinsics,
          ignoring any user-supplied versions. This enables the
          compiler to perform optimizations over calls to library
          routines based on special knowledge of the library.

          In this release, this flag is limited to -xknown_lib=blas and
          -xknown_lib=intrinsics.

             o -xknown_lib=blas

               The compiler recognizes calls to the following BLAS
               library routines and is free to do any optimizations
               appropriate for the Sun Performance Library
               implementation. Also, user-supplied versions of these
               library routines will not be compiled -- the Sun
               Performance Library BLAS routines will be referenced
               instead.

               The BLAS routines recognized by this option flag are:
               SDOT DDOT CDOTC ZDOTC CDOTU ZDOTU SAXPY DAXPY CAXPY
               ZAXPY SCOPY DCOPY CCOPY ZCOPY SSCAL DSCAL CSCAL ZXCAL

             o -xknown_lib=intrinsics

               Specifying intrinsics has the effect of ignoring any
               explicit EXTERNAL declarations for Fortran 95
               intrinsics, and ignoring any user-supplied intrinsic
               routines. For example,

               EXTERNAL SIN
               Y = SIN(X)

               would normally link the SIN(X) call with a user-supplied
               version of FUNCTION SIN(X) instead of the Fortran 95
               intrinsic routine. Compiling with -xknown_lib=intrinsics
               causes the EXTERNAL SIN to be ignored and the reference
               to be linked to the Fortran 95 intrinsic.

       6. Ignoring Dummy Argument Type in Interfaces

          A new directive, !$pragma IGNORE_TKR {name {, name} ...},
          causes the compiler to ignore the type, kind, and rank of the
          specified dummy argument names appearing in a generic
          procedure interface when resolving a specific call.

          For example, in the procedure interface below, the directive
          specifies that SRC can be any data type, but LEN can be
          either KIND=4 or KIND=8.

              INTERFACE BLCKX

                 SUBROUTINE BLCK_32(LEN,SRC)
                    REAL SRC(1)
              !$PRAGMA IGNORE_TKR SRC
                    INTEGER (KIND=4) LEN
                 END SUBROUTINE

                 SUBROUTINE BLCK_64(LEN,SRC)
                    REAL SRC(1)
              !$PRAGMA IGNORE_TKR SRC
                    INTEGER (KIND=8) LEN
                 END SUBROUTINE

               END INTERFACE

          The subroutine call:

                  INTEGER L
                  REAL S(100)
                  CALL BLCKX(L,S)

          will call BLCK_32 when compiled normally, and BLCK_64 when
          compiled with -xtypemap=integer:64. The actual type of S does
          not affect determining which routine to call. This greatly
          simplifies writing generic interfaces for wrappers that call
          specific library routines based on argument type, kind, or
          rank.

          Note that dummy arguments for assumed-shape arrays, Fortran
          pointers, or allocatable arrays cannot be specified on the
          directive. If no arguments are specified, the directive
          applies to all dummy arguments to the procedure, except dummy
          arguments that are assumed-shape arrays, Fortran pointers, or
          allocatable arrays.

       7. -xalias for Optimizing With Aliasing

          While the f95 compiler assumes that programs adhere to the
          Fortran 95 language standard regarding aliasing, many
          programs do not. This is particularly true of "dusty-deck"
          programs where intentional aliasing is used to overcome
          shortcomings of Fortran 77 (or earlier versions of Fortran).
          One example is overindexing arrays in COMMON blocks.

          Aliasing interferes with the compiler's assumptions about
          potential side-effects at high levels of optimization. The
          -xalias flag advises the compiler about how far the program
          deviates from the aliasing restrictions required by the
          Fortran 95 standard. The compiler is then better able to
          determine the appropriate optimizations to apply.

          The -xalias flag takes a comma-separated list of keywords.
          These are dummy, craypointer, actual, overindex, and
          ftnpointer. Each may appear with a prefix no% to turn off the
          subfeature.

          Current behavior, without -xalias specified, assumes no
          aliasing other than through Cray pointers, and is equivalent
          to:

           -xalias=no%dummy,craypointer,no%actual,no%overindex,no%ftnpointer

          Compiling with -xalias without arguments gives the best
          performance for programs that do not violate any of the
          Fortran rules about aliasing and do not use Cray pointers or
          Fortran 95 pointers. -xalias is equivalent to:

           -xalias=no%dummy,no%craypointer,no%actual,no%overindex,no%ftnpointer

       8. Enhancements to -C Runtime Checking

          In this release, runtime array subscript range checking with
          the -C compiler flag has been enhanced to also perform array
          conformance checking. For example, compiling the following
          with -C:

              integer a(10,10), b(10,10), m, n
              m = 5
              n = 6
              a(:,1:m) = b(:,1:n)
              end

          will produce a runtime error when the program executes:

          ******  FORTRAN RUN-TIME SYSTEM  ******
          An array expression does not conform : dim 2 is 6 , not 5
          Location: line 4 column 13 of 'check.f'

       9. The BYTE Data Type

          For compatibility with earlier versions of Fortran, this
          release of f95 accepts the BYTE data type and treats BYTE as
          INTEGER *1.

      10. Fortran 2000 Features

          Three new formatted I/O specifiers have been implemented in
          f95. These are part of the "Fortran 2000" draft language
          specification, and will become part of standard Fortran once
          the draft is approved.

          The new specifiers may appear on OPEN, READ, WRITE, PRINT,
          and INQUIRE statements:

             o DECIMAL=['POINT'|'COMMA']
               Change the default decimal editing mode. The default
               uses a period to separate the whole number and decimal
               parts of a floating-point number formatted with D, E,
               EN, ES, F, and G editing. DECIMAL='COMMA' changes the
               default to use a comma instead of a period (for example,
               123,456).
               DECIMAL='POINT' sets the default back to using period
               (123.456).

               Note that with DECIMAL='COMMA' the separator for
               displaying COMPLEX data changes to a semicolon:
               (123,45;7,0)

             o ROUND=['PROCESSOR_DEFINED'|'COMPATIBLE']
               Set the default rounding mode for formatted I/O for D,
               E, EN, ES, F, and G editing. With ROUND='COMPATIBLE',
               the value resulting from data conversion is the one
               closer to the two nearest representations, or the value
               away from zero if the value is halfway between them.
               With ROUND='PROCESSOR_DEFINED', the rounding mode is
               dependent on the processor's default mode, and is the
               default if ROUND is not specified.

               As an example, consider WRITE(*,'(f11.4)') 0.11115
               This will print 0.1111 in default mode, and 0.1112 in
               COMPATIBLE mode.

               ROUND options 'UP', 'DOWN', 'ZERO', and 'NEAREST' have
               also been implemented.

             o IOMSG=character-variable
               Returns an error message as a string in the specified
               character variable. This is the same error message that
               would appear on standard output. Users should allocate a
               character buffer large enough to hold the longest
               message. CHARACTER *256 should be sufficient.

          Note that on an INQUIRE statement, these specifiers declare a
          character variable for returning the current values.

          Also, the edit descriptors DP, DC, RP, and RC change the
          defaults within a single format to decimal point, decimal
          comma, rounding processor-defined, and rounding compatible,
          respectively. For example:

              WRITE(*,'(I5, DC, F10.3)') N, W

          a comma will appear in the printed output from the F10.3
          format instead of period.

          See also the -iorounding compiler option described next for
          changing floating point rounding modes.

      11. Rounding in Formatted I/O

          Use the new -iorounding option to set the default rounding
          mode for formatted I/O to processor-defined or compatible.
          These modes correspond to the ROUND= specifier described
          above.
          For example, -iorounding=compatible

      12. Obsolete Flags Removed

          The following obsolete f95 compiler option flags have been
          removed in this release:

           -db   -dbl

          The following f77 compiler options will not be implemented in
          the f95 compiler and are also considered obsolete.

            -arg=local  -dbl  -i2  -i4  -misalign  -oldldo
            -r8  -vax  -xl  -xvpara  -xtypemap=integer:mixed

      13. Check for Stack Overflow

          Compiling with -xcheck=stkovf adds a runtime check for stack
          overflow on suprogram entry. If a stack overflow is detected,
          a SIGSEGV (segmention fault) will be raised.

          Stack overflows, especially with multithreaded applications
          with large arrays allocated on the stack, can cause silent
          data corruption in neighboring thread stacks. Compile all
          routines with -xcheck=stkovf if stack overflow is suspected.

      14. New Default Thread Stack Size

          With this release, the default slave thread stack size has
          been increased to 4 Megabytes on SPARC V8 platforms, and 8
          Megabytes on SPARC V9 platforms. See the discussion of the
          STACKSIZE environment variable in the f95(1) man page for
          details.

      15. Enhanced Interprocedural Optimizations

          With -xipo=1, the compiler does inlining across all source
          files. With -xipo=2, the compiler adds interprocedural
          aliasing analysis and memory allocation and layout
          optimizations to improve cache performance.

      16. Prefetch Level

          Use the new option flag -xprefetch_level=n to control the
          automatic insertion of prefetch instructions with
          -xprefetch=auto

          You must be compiling with optimization level 3 or greater
          (-xO3) and generating code for a platform that supports
          prefetch (-xarch platforms v8plus v8plusa v8plusb v9 v9a v9b
          generic64 native64).

          Prefetch levels 2 and 3 are only effective on UltraSPARC III
          platforms (-xarch= v8plusb and v9b).

          -xprefetch_level=1 enables automatic generation of prefetch
          instructions. -xprefetch_level=2 enables additional
          generation beyond level 1. -xprefetch_level=3 enables
          additional generation beyond level 2.

          For f95, -xprefetch_level=2 is the default when
          -xprefetch=auto is specified.

     For information about other Forte Developer components, see the
     What's New manual. You can find this manual as part of the
     documentation installed with the Forte Developer 7 software, at
     file:/opt/SUNWspro/docs/index.html. You can also find the What's
     New manual in the Forte Developer 7 collection at
     http://docs.sun.com

     ------------------------------------------------------------------

     D. Software Corrections

        OpenMP Issues:

        * Assumed Shape Arrays:

          The OpenMP Fortran 95 API Specification Version 2.0 allows
          assumed shape arrays to appear on PRIVATE, FIRSTPRIVATE,
          LASTPRIVATE, and REDUCTION clauses. Previous release of f95
          did not support this feature while this release does.

          The OpenMP specification also states that the
          DEFAULT(PRIVATE) clause applies only to those variables that
          are allowed to appear explicitly in a PRIVATE clause. As a
          result, previous releases would not scope assumed shape
          arrays PRIVATE in a directive with DEFAULT(PRIVATE), while
          this release of f95 will.

          For greatest portability, users should explicitly declare
          assumed shape variables either PRIVATE or SHARED whenever
          they are used in a parallel region.

        * Allocatable Arrays:

          The OpenMP Fortran 95 API Specification Version 2.0 allows
          allocatable arrays to appear in a COPYPRIVATE clause.
          Previous releases of the f95 compiler did not support this
          feature.

        * Contained Subroutines:

          With this release a contained subroutine can be called from
          within a parallel region. Also, a contained subroutine can
          itself include a parallel region.



     ------------------------------------------------------------------

     E. Problems and Workarounds

     This section discusses known software problems and possible
     workarounds for those problems. For updates or patches, check the
     Forte Developer Hot Product News at
     http://www.sun.com/forte/fcc/hotnews.html.

        * VAX IDATE and TIME

          Programs using the legacy VAX Fortran IDATE or TIME library
          routines need to be compiled with -lf77compat 
          in this release. (4497980)

        * Roundoff in List-Directed Print

          List-directed PRINT statements compiled in Fortran 77
          compatibility mode (-f77) exhibit rounoff error when printing
          floating-point values very near 1.0. In particular:

             PRINT*, 0.9999999

          prints 0.100000 instead of 1.000000. Note that this occurs
          only in f77 compatibility mode, and only for values close to
          1.0. (4665593).
          (Fixed in patch 111714-01)

        * Problems with -xalias

          At optimization levels -O3 and higher, -xalias=dummy and
          -xalias=actual may still permit unsafe optimizations in
          situations involving aliasing caused by dummy and actual
          arguments. Compile at -O2 to avoid these unsafe
          optimizations. (4558736,4646796)
          (Fixed in patch 111714-01)

        * Renaming subprograms in USE statements

          At optimization levels -O3 or higher, referencing an external
          subprogram that has been renamed in a USE statement from a
          module causes a linker error. (4647517)
          (Fixed in patch 111714-01)

        * Problems with -xtypemap=integer:64

          Compiling with -xtypemap=integer:64 in Fortran 77
          compatibility mode -- in particular -f77=logical -- may
          result in an internal compiler error at optimization levels
          -O2 or higher. (4646445)
          (Fixed in patch 111714-01)

        * ALLOCATABLE and derived type arrays

          Multi-dimensional automatic arrays with default
          initializations (including allocatable and pointer
          components, which are implicitly initialized to NULL) can
          cause a segmentation fault at runtime when compiling at -O2
          or higher. (4511902)
          (Fixed in patch 111714-01)

          Assignments of arrays of derived type can cause an internal
          compiler error when compiled at -O2 or above if the derived
          type contains allocatable components and the assignment is
          inside a WHERE statement or block. (4643904)
          (Fixed in patch 111714-01)

        * Intrinsics CBRT and CQCBRT on V9 platforms

          When compiling with -f77 -xarch=v9, the intrinsics CBRT and
          CQCBRT can give incorrect results when called with 16-byte
          arguments. A workaround is to add explicit declarations for
          these intrinsics:

             COMPLEX*32 CQCBRT
             REAL*16 CBRT

          (4647084)
          (Fixed in patch 111714-01)

        * Recursive calls require -stackvar

          Programs that do implicit recursive subprogram calls (without
          the RECURSIVE attribute) should be compiled with -stackvar as
          well as -f77 or -xrecursive. In some cases, the compiler
          fails to implicitly declare objects as automatic unless
          -stackvar is explicitly specified. (4641751)
          (Fixed in patch 111714-01)

        * Legacy VAX TYPE statement not always recognized.

          The compiler does not always correctly distinguish the VAX
          TYPE (print) statement from the Fortran 95 derived TYPE
          statement in certain contexts. For example, following an IF,
          as in:

             IF(A.EQ.B) TYPE *, 'A EQUALS B'

          A workaround is to use PRINT instead of TYPE. (4643548)
          (Fixed in patch 111714-01)

        * Problems with -xknown_lib

          -xknown_lib=blas can cause incorrect code to be generated
          when the affected routines are asked to operate on arrays of
          dimension two or greater. The incorrect code could cause a
          segmentation fault. The routines affected by the flag are all
          1-dimensional blas1 routines, but they can be legally called
          to operate on vectors within higher dimensional arrays, and
          that is the case that generates incorrect code. Compiling
          with -xknown_lib=blas can also cause an internal error in the
          compiler or bad code to be generated when the array argument
          is an assumed-size formal parameter. (4652652)
          (Fixed in patch 111714-01)

        * Problems with -Xlistf

          Compiling with -Xlistf, (fast cross-reference listing without
          compiliation), may generate incorrect .o object files that
          cannot be linked into executables. This may also cause
          problems for programs maintained by make, preventing later
          invocations of make to properly update files. A workaround is
          to manually delete .o files generated by a compilation with
          -Xlistf, or to do a make clean after such compilations.
          (4655434)
          (Fixed in patch 111714-01)

        * OpenMP Problems

          The following problems have been noticed with the Fortran 95
          implementation of the OpenMP API:

             o ATOMIC directive

               Certain incorrect uses of the ATOMIC directive are
               silently accepted. The code should run as expected, but
               is in violation of the OpenMP standard. (4458810)

             o Reductions sometimes fail inside WORKSHARE

               Use of a reduction intrinsic inside of an "orphaned"
               WORKSHARE directive may cause a runtime error or
               incorrect results. (4433331)

             o Reduction of an array of type QUAD COMPLEX

               Compilation of a program with a reduction array of type
               quad complex (complex(16)) fails, when the reduction
               array is a formal argument in a subroutine or is
               accessed by host-association, as in the following
               examples:

               Example 1: Quad-complex reduction array appears as a
               formal argument in a subroutine:

                     subroutine reduce(zz)
                     complex(16):: zz(30)
                     integer i, j

               !$omp parallel
               !$omp do reduction(+:zz) private(j)
                     do i = 1, 10
                        do j=1,30
                           zz(j)=zz(j)+(0.033d20,0.033d20)
                        enddo
                     end do
               !$omp end parallel
                     end

               Example 2: Quad-complex reduction array accessed via
               host association:

                     complex(16):: zz(30)

                     contains
                     subroutine reduce
                     integer i, j

               !$omp parallel
               !$omp do reduction(+:zz) private(j)
                     do i = 1, 10
                        do j=1,30
                           zz(j)=zz(j)+(0.033d20,0.033d20)
                        enddo
                     end do
               !$omp end parallel
                      end subroutine
                     end

             o Reduction of an assumed-share array

               Program with reduction of an assumed-shape array fails
               to compile, if the reduction array is only referenced in
               a call in the body of the parallel region where the
               reduction clause appears, as in the following example:

                     subroutine sub_1(a)
                     integer a(:)

               !$omp parallel reduction(+:a)
                     call sub_2(a)
               !$omp end parallel
                     end subroutine sub_1



     ------------------------------------------------------------------

     F. Limitations and Incompatibilities

     This section discusses limitations and incompatibilities with
     systems or other software.

        * Interval Function Calls

          In this release the interface (ABI) for interval function
          calls has been changed, and is not binary compatible with
          previous releases. This means that programs and libraries
          with interval functions must be recompiled with Forte
          Developer 7 f95. In particular, Fortran interval functions
          called by C++, and C++ interval functions called by Fortran,
          must be recompiled with the Forte Developer 7 f95 and CC
          compilers.

        * CHARACTER*1 Call-by-Value Interfaces

          This release of Fortran 95 introduces an incompatibility with
          the previous release in the way it passes CHARACTER*1 in
          subprogram calls designated with a VALUE attribute in
          interface blocks.

          The difference is transparent for correctly written Fortran
          95 programs compiled with this release of f95. This
          difference becomes an issue when the caller and the called
          routine are compiled with different compiler releases, or
          when one or the other is written in C.

          Consider this example:

          main.f:
                  interface
                  subroutine s(c1,c2)
                  character*1, value :: c1   !  c1 is call-by-value
                  character*2 :: c2
                  integer I
                  end subroutine
                  end interface
                  call s('A', 'BC')
                  end

          sub.f:
                  subroutine s(c1,c2)
                  character*1, value :: c1
                  character*(*) :: c2
                  print *, 'You passed ',c1,' and ',c2
                  END

          With main.f compiled with the previous release of the
          compiler and sub.f compiled with this release, the program
          incorrectly produces:

           You passed A and B

          This release of the compiler passes call-by-value CHARACTER
          *1 data without a character length parameter. In all other
          cases, character data is passed with a hidden length
          parameter generated automatically by the compiler as part of
          the call. (Note that Fortran 95 restricts call-by-value of
          CHARACTER data to only CHARACTER*1.)

          Similarly, C routines calling or called by Fortran 95
          routines that expect call-by-value CHARACTER*1 data must be
          rewritten to no longer expect a length parameter for those
          arguments.

        * Linking on SPARC V9 Platforms Under Solaris 7 and 8:

          Many static system libraries, such as libm.a and libc.a, are
          not available in Solaris 7 or 8 environments on SPARC V9
          platforms. Only dynamic, shared libraries, libm.so and
          libc.so, are provided. This means that -Bstatic and -dn
          compiler options could cause linking errors on SPARC V9
          platforms with Solaris 7 or 8. Applications must use dynamic
          libraries in these cases.

          To explicitly link with a static version of a user library
          while linking dynamically system libraries, use a command
          line that looks something like:

            f95 -o prog prog.f -Bstatic -lxyz -labc -Bdynamic

          This will link with libxyz.a and libabc.a, but all other
          libraries, including system libraries, will be linked
          dynamically.

        * Array Intrinsic Functions Use Global Registers:

          The array intrinsic functions ANY, ALL, COUNT, MAXVAL,
          MINVAL, SUM, PRODUCT, DOT_PRODUCT, and MATMUL are highly
          tuned for the appropriate SPARC platform architectures. As a
          result, they use the global registers %g2, %g3, and %g4 as
          scratch registers.

          User code should not assume these registers are available for
          temporary storage if calls are made to the array intrinsics
          listed above. Data in these registers will be overwritten
          when the array intrinsics are called.

        * F95 Modules in Archive Libraries Not Included In Executable:

          The debugger dbx requires all object files used in the
          compilation  to be included in the executable file.  Usually,
          programs satisfy this requirement with no extra work on the
          part of the user.  An exceptional case arises from the use of
          archives containing modules. If a program uses a module, but
          does not reference any of the procedures or variables in the
          module, the resulting object file will not contain references
          to the symbols defined in the module. The linker only links
          with a object file from an archive if there is a reference to
          a symbol defined in the object file.  If there is no such
          reference, the object file will not be included in the
          executable file.  Dbx will give a warning when it tries to
          find the debugging information associated with the module
          that was used. It will not be able to provide information
          about the symbols whose debugging information is missing.

          Use the -u linker option to work around this problem. This
          option takes a symbol as its option argument.  It adds that
          symbol to the set of undefined linker symbols, so it will
          have to be resolved.  The linker symbol associated with a
          module is normally the module name with all letters in lower
          case followed by an underscore.

          For example, to force the object file containing the module
          MODULE_1 to be taken from an archive, specify the linker
          option -u module_1_.  If  linking using the f95 command, use
          the  -Qoption ld -umodule_1_ on the command line.

        * Fortran 95 Derived Types and SCCS:

          Because of SCCS's use of the percent sign (%) to delimit
          single-letter ID keywords, users with Fortran 95 programs
          that define structure components with single-letter names
          could see unexepected results when maintaining their source
          code files under SCCS.

          This is not necessarily a bug in the compiler, but rather a
          conflict between the Fortran 95 language and the SCCS source
          code control system.

          It can be avoided by not using single letter names for
          structure components if you plan to manage your source codes
          with SCCS, or by retrieving the files with the SCCS get
          option -k which ignores these keywords, or by placing blanks
          around the %, as in X % Y % Z.

        * Binary Incompatibility with Forte Developer 6 update 2 Object
          Files

          This release of f95 fixes a problem where the -aligncommon
          flag did not properly align derived types or variables typed
          with an explicit KIND.

          For example, the following program:

              character*26 type

              logical(1) :: l1 = .true.
              real(16)   :: r16 = 1
              integer(2) :: i2 = 1

              common /A/ l1,r16,i2

              print *, '--------------------------------------------'
              print *, ' Fortran 95 COMMON-block alignment in Bytes '
              print *, '--------------------------------------------'

              type = 'logical(1)'
              print *, type, loc(l1)-loc(l1)

              type = 'real(16)'
              print *, type, loc(r16)-loc(l1)

              type = 'integer(2)'
              print *, type, loc(i2)-loc(l1)

              end

          when compiled with FD6u2 Fortran 95 with -aligncommon
          produces the following output:

           --------------------------------------------
            Fortran 95 COMMON-block alignment in Bytes
           --------------------------------------------
           logical(1)                 0
           real(16)                   8
           integer(2)                 24

          whereas it should produce (and does, in this FD7 f95
          compiler)

           --------------------------------------------
            Fortran 95 COMMON-block alignment in Bytes
           --------------------------------------------
           logical(1)                 0
           real(16)                   1
           integer(2)                 17

          If you compile with the -aligncommon option you should not
          mix FD6U2 object files with objects produced by the FD7
          compiler if the common blocks contain either derived types or
          variables typed with an explicit kind value.



     ------------------------------------------------------------------

     G. Documentation Errors

     There is no new information at this time.



     ------------------------------------------------------------------

     H. Required Patches for Fortran 95

     For information about required and optional patches for this Forte
     Developer release, see the Forte Developer 7 Release Notes. The
     release notes appear as a text file on the Forte Developer 7 CD at
     /cdrom/devpro_v10n1_sparc/release_notes.txt. These release notes
     are also available through the documentation index page on the
     Forte Developer 7 web site at
     http://www.sun.com/forte/fcc/documentation.

     Check also the latest news at
     http://www.sun.com/forte/fcc/hotnews.html.



     ------------------------------------------------------------------

     I. Shippable Libraries

     If your executable uses a Sun dynamic library listed in the file
     named below, your license includes the right to redistribute the
     library to your customer.

        /opt/SUNWspro/READMEs/runtime.libraries

     Note - If your Forte Developer 7 software is not installed in the
     /opt directory, ask your system administrator for the equivalent
     path on your system.

     You cannot 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,
     which you can view from the back of the plastic case containing
     the CD-ROM.



     ------------------------------------------------------------------

     Copyright  2002 Sun Microsystems, Inc. All rights reserved. Use
     is subject to license terms.
