Contents

1. Introduction
2. About Sun Studio 12 Fortran 95
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 this release of the Sun[tm] Studio 12 Fortran 95 compiler, f95. This document describes the software corrections, known problems, limitations, and incompatibilities of this release.

Product Documentation

Product documentation for this release of Sun Studio includes the following:

• Release Notes: Available on the Sun Studio web site at http://developers.sun.com/sunstudio/documentation/ss12/release_notes.html. Information in the release notes updates and extends information in all readme files.
• Compilers and Tools Documentation: Product man pages, HTML versions of readmes, and manuals can be accessed from /installation_directory/SUNWspro/docs/index.html. The default installation directory for Solaris platforms is /opt. If your Sun Studio  software is not installed in the default /opt directory, ask your system administrator for the equivalent path on your system.

---

B. About Sun Studio 12 Fortran 95

This readme has been updated with information describing new and changed features in this release of f95.

Version 8.3 of the Fortran 95 compiler f95 is released as a component of Sun Studio 12, and is available on Solaris Operating System (Solaris OS) versions 9, and 10, on SPARC(R)  and x86 platforms, and on Linux x86/x64 platforms.

The previous version of the compiler was version 8.2, released with Sun Studio 11 .

---

C. New and Changed Features

This section describes new and changed features for this release of Fortran 95. For details on any of the compiler options, see the Fortran User's Guide and the f95(1) man page.

New Features and Updates Common To All Compilers on SPARC and x86 Platforms

A New Way To Specify 32-bit or 64-bit Address Model

You no longer need use the -xarch option to specify a 32-bit or 64-bit address model (LP64 versus ILP32). Two new options make it easier:

• -m32 specifies the ILP32 model: 32-bit ints, longs, and pointer types.

• -m64 specifies the LP64 model: 32-bit ints, 64-bit longs and pointers types. (Note that -m64 is the default on Linux platforms.)

Deprecated -xarch Flags and Their Replacements Across SPARC and x86

• Use -m64 in place of -xarch=generic64

• Use -m64 -xarch=native in place of -xarch=native64

If you are using -xarch=v9 or -xarch=amd64 to specify a 64-bit address model, use just -m64 instead. No -xarch value is required.

Deprecated -xarch Flags and Their Replacements on SPARC Only

• Use -xarch=sparc in place -xarch=v8plus

• Use -xarch=sparcvis in place of -xarch=v8plusa

• Use -xarch=sparcvis2 in place of -xarch=v8plusb

• Use -xarch=sparc -m64 in place of -xarch=v9

• Use -xarch=sparcvis -m64 in place of -xarch=v9a

• Use -xarch=sparcvis2 -m64 in place of -xarch=v9b

Deprecated -xarch Flags and Their Replacements on x86 Only

• Use -xarch=sse2 -m64 in place of -xarch=amd64.

• Use -xarch=sse2a -m64 in place of -xarch=amd64a.

Disallowed Combinations and Warnings

The compilers do not allow the combination of a deprecated -xarch value and the new -m32, -m64 options on the command line. For example, specifying -xarch=v9 -m32 is now a fatal error. Specifying -xarch=sparc -xarch=v9 is also a fatal error.

Some older -xarch values do not have 64-bit counterparts. You cannot combine the following -xarch options with -m64 on the command line:

  For SPARC platforms: -xarch=v7, -xarch=v8, -xarch=v8a
  For x86 platforms: -xarch=386, -xarch=pentium_pro, -xarch=pentium_proa, -xarch=sse, -xarch=ssea

If you specify a 32-bit -xarch value followed by -m64, the compiler does not issue a warning. For example -m64 -fast or -fast -m64 are allowed. However, if you specify a 64-bit -xarch value followed by -m32, the compiler issues a warning that -m32 overrides the -xarch value. This situation does not occur using macro options, only when an -xarch option has been explicitly specified.

New x86 Features and Updates Common To All Compilers

The following are new x86 flags for the -xarch option:

• -xarch=sse3 specifies that the compiler should generate instructions based on both the SSE3 and SSE2 architectures.

• -xarch=sse3a specifies that the compiler should generate instructions based on the SSE3, SSE2 and AMD extended architectures as well as the 3DNow extensions.

Changes to -fast Option

The -fast option on x86 now includes -xregs=frameptr, which means that the compiler can use the frameptr register (%ebp on IA32, %rbp on AMD64) as a general purpose register to generate code for all the compilation units. Consequently frame pointers will not be generated in each function or routine.

However, if you want to override this new behavior, specify -xregs=no%frameptr after -fast in the compilation command and the frameptr register will not be used as a general purpose register. The following example demonstrates how to override the -fast default for -xregs:

      cc -fast -xregs=no%frameptr foo.c

New SPARC Features and Updates Common To All Compilers

This release of the Sun Studio compilers includes support for the SPARC64 VI and UltraSPARC T2 processors. Use the following new options to specify these processors:

• -xtarget=sparc64vi

• -xtarget=ultraT2

You can also specify the following -xchip options to generate code for these processors without setting the -xarch value automatically as happens when you use -xtarget:

• -xchip=sparc64vi

• -xchip=ultraT2

New Math and Visual Instruction Set Support in SPARC64 VI

Specify the following new option if you want to use instructions from the SPARC-V9 instruction set including the UltraSPARC extensions, the Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III extensions, the Visual Instruction Set (VIS) version 2.0, and the SPARC64 VI extensions for floating-point multiply-add:

• -xarch=sparcfmaf

• -xarch=sparcvis2

You must also specify -m32 or -m64 when you specify -xarch=sparcfmaf to get 32-bit code or 64-bit code respectively . When you specify -xarch=sparcfmaf, the compiler predefines the following new values:

• -D__FP_FAST_FMA__

• -D__FP_FAST_FMAF__

Note: You must use -xarch=sparcfmaf in conjunction with the new -fma=fused option detailed below and some optimization level in order for the compiler to find opportunities to use the multiply-add instructions automatically.

New Option for Floating-Point, Fused or Multiply-Add Instructions

Specify the following new option to enable or disable the automatic generation of floating-point, fused, multiply-add instructions:

• -fma={none,fused}

The none value indicates that the compiler should not generate any floating-point, fused, or multiply-add instructions. The fused value allows the compiler to attempt to find opportunities to improve the performance of the code by using floating-point, fused, or multiply-add instructions.

Linux Support

This release of the Sun Studio compilers supports the Linux OS. See the release notes for processor and distro version requirements.

There are some limitations with f95 on Linux. See Section F. below for details.

The New Thread Analyzer

The following new compiler option causes the compiler to instrument your multi-threaded application for analysis by the new Thread Analyzer. 

• -xinstrument[=[no%]datarace]

The default is -xinstrument=no%datarace.

Additional Notes:

• Support for interval arithmetic on Solaris Intel platform with the -xarch=sse2 -xia options.

• CAUTION messages issued when using the same symbols that are defined in different modules.This enhancement provides a CAUTION level message when the same symbols defined in different modules are imported by the USE statement. This helps isolating name duplication problems in large applications using third-party modules.
  

• Faster compilation time for source files with many constant values.
  
  
• Intrinsic functions called with UNSIGNED arguments improved.

• Improved backward compatibility with old F77 objects produced by the Sun WorkShop 6 update 2 compiler.

---

D. Software Corrections

No information at this time.

---

E. Problems and Workarounds

This section discusses known software problems in this release and possible workarounds for those problems.

Library Links on Linux Incorrect
The links for the library libfui.so on Linux are incorrect. To fix the links, remove the existing links for libfui.so from installation-directory/lib and from installation-directory/lib/amd64 and recreate the links in those directories with the command


              ln -s libfui.so.1 libfui.so

If the links are not corrected, programs will link with the archive version of libfui. If programs are linked with the archive versions of some of the f95 run-time libraries and shared object versions of other of the f95 libraries, the resulting executables might fail when the shared objects are updated.

---

F. Limitations and Incompatibilities

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

Known Limitations on Linux

• In this release, setting options -ftrap, -fround, -fprecision, or -fns has no effect on Linux. Only the defaults are used, except for -ftrap, which is -ftrap=%none on Linux instead of -ftrap=common. Check SunSolve to see if this is corrected in a subsequent patch.
• The -xprofile=collect and -xprofile=tcov options should not be used when building shared libraries on Linux.
• Man Pages on Linux:
  Some man pages get errors from the man(1) command. HTML versions of the man pages on Linux are only available on the portal at http://developers.sun.com/sunstudio/documentation/ss12.
  

Previous releases of the f95 compiler introduced incompatibilities that carry forward to this release of the compiler and should be noted if you are updating from earlier f95 releases. The following incompatibilies are worth noting:

• Interval Function Calls

The interface (ABI) for interval function calls was changed in the Forte Developer 7 release, and is not binary compatible with the ABI for Sun WorkShop 6 update 2 and earlier releases. This means that programs and libraries with interval functions must be recompiled with the current f95. In particular, Fortran interval functions called by C++, and C++ interval functions called by Fortran, must be recompiled with the f95 and CC compilers.

• CHARACTER*1 Call-by-Value Interfaces

Fortran 95 version 7.0 introduced 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 versions 7.0 or 8.0 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

The compiler now 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.

• Binary Incompatibility with Forte Developer 6 update 2 Object Files

Version 7.0 f95 fixed 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 (version 6.2) 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, with versions 8.0 and 7.0 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 version 8.0 or 7.0 compiler if the common blocks contain either derived types or variables typed with an explicit kind value.

The following general items should also be noted:

Linking on SPARC V9 Platforms under OS releases since Solaris 7:

Many static system libraries, such as libm.a and libc.a, are not available in recent Solaris OS releases 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. 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.

---

G. Documentation Errors

No information at this time.  Additional information may be made available at http://developers.sun.com/sunstudio/

---

H. Required Patches for Fortran 95

For information about required and optional patches for this release, see the Sun Studio release notes at http://developers.sun.com/sunstudio/documentation/ss12/release_notes.html.

---

I. Shippable Libraries

If your executable uses a Sun dynamic library listed at http://developers.sun.com/sunstudio/documentation/ss12/mr/runtime.libraries.html, your license includes the right to redistribute the library to your customer.

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 © 2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.