Contents

1. Introduction
2. About the Forte Developer 7 Release
3. New and Changed Features
4. Software Corrections
5. Problems and Workarounds
6. Limitations and Incompatibilities
7. Documentation Errors
8. Required Patches for Fortran 95
9. 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:

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

   But note the following:

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

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

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

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

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

   • -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

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

    • 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)

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

    • 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, check 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 explicitly link with /opt/SUNWspro/prod/lib/libF77.so.4, as well as be compiled with -lV77, in this release. (4497980)

• 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)

• 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. (4511902)

• 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)

• 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)

  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)

• 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)

• 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)

• 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, 4645652)

• Optimization Problems

  Some new optimizations were found to have bugs that can cause some applications to give incorrect results or quit unexpectedly due to improperly generated code. In general, the workaround is to step down the optimization level and to specify -inline=%none. (4616033)

• 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)

• 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)

• OpenMP Problems

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

  • 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)

  • 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)

  • 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
    

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