IntelŪ Visual Fortran Compiler 9.0 for Windows*
Release Notes

Contents

Overview

This product provides tools for Windows* software developers to create applications that run at top speeds on all IntelŪ IA-32 processors, Intel processors with IntelŪ Extended Memory 64 Technology (IntelŪ EM64T) and Intel ItaniumŪ 2 processors. Optimizations include support for Streaming SIMD Extensions 2 (SSE2) in the Intel PentiumŪ 4 and Intel Pentium® M processors, Streaming SIMD Extensions 3 (SSE3) in the Intel Pentium 4 processors with SSE3 support, and software pipelining in the Intel ItaniumŪ 2 processor. Inter-procedural optimization (IPO) and profile-guided optimization (PGO) can provide greater application performance. Intel Compilers support multi-threaded code development through autoparallelism and OpenMP* support.

The Standard Edition of this product consists of the IntelŪ Visual Fortran Compiler, the IntelŪ Debugger, the IntelŪ Array Visualizer, integration into Microsoft* Visual C++* .NET* 2002 or 2003, and code coverage and test prioritization tools. The Professional Edition includes all of the Standard Edition features and adds the IMSL* Fortran Libraries 5.0 from Visual Numerics.

Compatibility

You must recompile all Fortran sources that were compiled with Intel Fortran versions earlier than 8.0, including those that create .mod files. If you are using third-party libraries and/or .mod files, you must obtain compatible versions from the library vendor. If you encounter difficulties obtaining updated third-party libraries, please let us know through IntelŪ Premier Support. If you previously used Compaq* Visual Fortran (CVF), note that the default procedure calling and naming conventions are different from CVF. A document describing CVF porting considerations is available from http://developer.intel.com/software/products/compilers/fwin/ or from IntelŪ Premier Support.

Product Contents

This product contains the following components:

Note: the default installation master directory referred to as <install-dir> in this document is C:\Program Files\Intel. The Fortran 9.0 compiler is installed into the Compiler\Fortran\9.0 subfolder.

To receive technical support and product updates for the tools provided in this product you need to register, as described in the Technical Support section.

Changes in Version 9.0

The following section discusses new features and changes in the Intel Visual Fortran Compiler version 9.0 and updates to 9.0. Please see the separate release notes for the Intel Array Visualizer and the Intel Debugger. For a quick summary of changes after the 9.0 release, please refer to the Change History.

Compiler

New Compiler Options

The following table lists compiler options that provide new functionality in this release.

Some compiler options are only available on certain systems, as indicated by these labels:

Label Meaning

i32

The option is available on IA-32-based systems

i32em

The option is available on IA-32-based systems with IntelŪ Extended Memory 64 Technology (IntelŪ EM64T)

i64

The option is available on ItaniumŪ-based systems

If no label appears, the option is available on all supported systems.

If "only" appears in the label, the option is only available on the identified system.

For more details on the options, refer to the Alphabetical Compiler Options section of the Intel Visual Fortran Compiler for Windows User's Guide.

Option Description
-allow [no]fpp_comments Specifies the comment style in fpp-preprocessed source. See below for more details.

-check [no]uninitialized
or /check:[no]uninitialized
or /CU

Determines whether checking occurs for uninitialized variables.

/debug-parameters:all Specifies that debug information should be generated for all declared PARAMETER constants
/debug-parameters:used Specifies that debug information should be generated for only those PARAMETER constants used in the code. Same as /debug-parameters
/debug-parameters:none Specifies that debug information should not be generated for PARAMETER constants

-f[no-]omit-frame-pointer
i32 only

Indicates whether the compiler should use the frame pointer for IA32. -fno-omit-frame-pointer is a synonym for -fp.

-ftrapuv or /Qtrapuv

Initializes stack local variables to an unusual value that may help detect uninitialized variables.

-funroll-loops

Tells the compiler to unroll used loops based on the default optimization heuristics. Synonym for -unroll.

-[no]gen-interfaces or /[no]gen-interfaces

Tells the compiler to generate an interface block for each routine in a source file.

-[no-]global-hoist or
/Qglobal-hoist[-]

Determines whether certain optimizations are enabled that can move memory loads to a point earlier in the program execution than where they appear in the source.

-i-static

Links Intel-provided libraries statically.

-map-opts or /Qmap-opts

Enables a tool that maps a command line to another platform (Windows* to Linux* or vice versa).

-m[no-]ieee-fp

Controls whether the compiler uses IEEE floating point comparisons.

-mtune=<keyword>

Performs optimizations for a particular CPU.

-[no-]prec-sqrt or
/Qprec-sqrt[-]
i32, i32em only

Determines whether or not to disable certain optimizations that improve performance of square root operations while slightly reducing precision.

/Qsox Causes the compiler to save compiler version and compilation options in the object and executable files (New for i64)

-ssp or /Qssp
i32 only

Enables the software-based speculative pre-computation (SSP) optimization to generate prefetching helper threads.

--version

Displays compiler version information.

-warn [no]interfaces or /warn:[no]interfaces

Lets you check the interfaces of all SUBROUTINEs called and FUNCTIONs invoked in your compilation - used in conjunction with /gen-interfaces.

-WB

Turns a compile-time bounds check error into a warning.

New Language Features

The following features from the Fortran 2003 standard are now supported by the Intel Fortran Compiler: These features are described in Language Reference Manual and are not further discussed here. Additional Fortran 2003 features, implemented after the initial 9.0 release, are described later in these Release Notes.

The following is a list of additional new and changed language features. Please see the Intel Fortran Language Reference for more information.

Loop Directives May Now Be Used For Array Assignments

Loop directives such as IVDEP and NOUNROLL may now be placed preceding array assignments and will apply to loops generated by the compiler for such assignments. For more information, see the Language Reference section "Rules for Loop Directives that Affect Array Assignment Statements" in the chapter on Directives.

OpenMP WORKSHARE Directive Supported

The OpenMP* 2.0 WORKSHARE directive is now supported.

IF and DO Nesting Maximum Level Increased to 256

The maximum nesting level for IF and DO constructs (combined) has been increased from 128 to 256.

Choice of Comment Style in fpp-Preprocessed Source

The /allow:[no]fpp_comments switch has been introduced in order to allow the user to control how the fpp preprocessor treats Fortran end-of-line comments in preprocessor directive lines. Consider for example the following source line:

#define MAX_ELEMENTS 100 ! Maximum number of elements

How is the preprocessor supposed to treat the text "! Maximum number of elements"? Is it treated as a Fortran comment and therefore ignored, or is it part of the value for the MAX_ELEMENTS definition? Given that the functionality of fpp is essentially that of the C preprocessor cpp, and on many platforms, a cpp itself is used to provide Fortran preprocessing, to cpp, this would just be text that is part of the value being defined..

The Intel Fortran Compiler default, specified by /allow:fpp_comments, is to recognize Fortran-style end-of-line comments on preprocessor lines. Therefore, by default, the line above would define MAX_ELEMENTS to be simply "100". If /allow:nofpp_comments is specified, then Fortran end-of-line comment conventions are not used and "!" has no special meaning. An example of where you may want to use /allow:nofpp_comments is to have a Fortran directive as a define value, for example:

#define dline(routname) !dec$ attributes alias:"__routname":: routname

Please note that there is not widespread agreement among Fortran vendors for this behavior.

If you are using the Visual Studio IDE, you must enter this switch manually under Command Line in the Fortran project property page.

Debug Information for PARAMETER Constants

The compiler is now able to generate debug information for numeric (scalar and array) PARAMETER constants, so that the values of these may be examined while debugging. Character and derived type constants are not supported in this version. The new -debug-parameters option controls this feature. If /debug-parameters is specified with no other keyword, the default is used, meaning that only those PARAMETER constants used in the source will be visible in the debugger. /debug-parameters:all specifies that all declared PARAMETER constants shall be visible - this can significantly increase code size. /debug-parameters:none disables generation of debug information for PARAMETER constants - this is the default if /debug-parameters is not specified.

Automatic Interface Checking

The compiler is now able to perform some degree of consistency checking between call and called routine in an application in the absence of explicit interfaces, even across multiple source files. The new /gen-interfaces option instructs the compiler to generate and compile a Fortran module source with an explicit interface for all global procedures not in a module. The names of the generated files are based on the procedure name with a suffix of "_mod" and the file type .f90 or .mod. The generated interface includes name, type and rank of each dummy argument. At present, it does not include other attributes such as INTENT and OPTIONAL that may have been specified in the procedure.

The new /warn:interfaces option instructs the compiler to look for a generated module of the appropriate name when it sees a reference to a procedure lacking an explicit interface. If it finds one, it behaves as if a USE of that module had been specified for the program unit being compiled. If the call is inconsistent with the implicitly imported interface, the compiler issues a diagnostic message as if the same interface had been explicitly specified.

For best results, specify both /gen-interfaces and /warn:interfaces. The compiler will ensure that all calls within a source file are properly verified. Calls to procedures in separately compiled source files will be verified if the other source was compiled first. In the Microsoft Visual C++ IDE, /gen-interfaces is specified on the External Procedures property page as Generate Interface Blocks and /warn:interfaces is specified on the Diagnostics property page as Check Routine Interfaces.

Run-Time Checking for Uninitialized Variables

The compiler now has the ability to perform run-time checking for variables which are used before their value is defined. The option to request this checking is /check:uninitialized (/CU and ./RTCu are acceptable synonyms.) Note that this option will be implicitly selected if you specify /check, /check:all or /C.

The compiler can detect most uses of uninitialized local scalar variables within a compilation unit.

When an uninitialized use is detected and the program is built with debug libraries and run under control of the debugger in Visual Studio.NET, an error is signaled and a detailed message displayed naming the variable, along with a traceback if that option was enabled. If the program is not running under the control of the Visual Studio.NET debugger, a generic "user breakpoint" error will be seen. In a future version, the intent is to display the detailed message under all circumstances.

Use of /QxP and /QaxP Code Generation Switches

The /QxP and /QaxP switches specify generation of specialized code for Intel processors supporting the Streaming SIMD Extensions 3 (SSE3), including the Intel® Core™ processors.

Additional Optimization at /O2

When the default optimization level (/O2) is specified, the compiler now performs certain interprocedural and loop optimizations that were formerly performed only when /Qip or /O3 were specified. We invite your comments as to the effect of this change on performance (both run-time and compile-time) as well as application results.

Optimization Improvements

The compiler is now able to vectorize loops made parallel through the use of OpenMP directives. Additional optimization improvements have been made that could lead to improved performance. Examples are loop blocking for better cache utilization; runtime dependency checking and loop versioning.

Loop Optimization Reports Improved

A number of improvements have been made to the optimization reports. For example, loop optimization reports, selected with -opt_report_phase:hlo, now have more detailed line number information for unrolled loops, and identifiers for multiple versions of loops.

Multiple Object Default for /Qipo

When /Qipo is specified, the compiler now, by default, can produce multiple intermediate object files for input to the linker, rather than a single file. This can improve performance of the link phase. You can adjust this behavior by specifying a value for /Qipo. Please refer to the Compiler Options Guide for more information.

Software-based Speculative Pre-Computation (IA-32 only)

The new /Qssp option enables Software-based Speculative Pre-computation (SSP) optimization, which is also called Helper-Threading optimization. This feature provides a way to dynamically prefetch data cache blocks to reduce the impact of memory latency. It exploits the properties of source code constructs (such as delinquent loads and pointer-chasing loops) in applications.

SSP directly executes a subset of the original program instructions, called a slice, on separate threads alongside the main computation thread, in order to compute future memory accesses accurately. The helper threads run ahead of the main thread and trigger cache misses earlier on its behalf, thereby hiding the memory latency.

To be effective, SSP techniques require construction of efficient helper threads and processor-level support, such as Hyper-Threading Technology (HT Technology) support, which allows multiple threads to run concurrently with a shared cache. These techniques include:

The results of SSP vary because each program has a different profile and different opportunities for SSP optimizations. For guidelines to help you determine if you can benefit by using SSP, see the topic "Software-based Speculative Precomputation (IA-32)" in the Profile-Guided Optimization section of your Optimizing Applications guide.

CALL of Function with Implicit Interface No Longer Allowed

In previous versions of the compiler, a CALL to a name given a type, thus making it a function with an implicit interface, was allowed in some cases. For example:

REAL F
CALL F(X)

This is not allowed by the Fortran language, and, depending on the platform and the actual or declared datatype of the function, could cause corruption of the floating point stack. As of version 9.0, attempting to CALL a typed identifier will give an error. If your application took advantage of this feature, replace the CALL with a function reference assigned to a variable. Note that a CALL to a function with an explicit interface has not been allowed in the past - that behavior has not changed.

Mismatch of Argument KIND Now Diagnosed

In previous versions, the compiler would silently allow a mismatch of KIND for an argument when calling a routine that had an explicit interface. For example, consider the following:

interface
  subroutine sub (x)
  real(8) :: x
  end subroutine sub
end interface
...
call sub(3.0)

The 3.0 in the call is of type "default real", or real(4). Previously, the compiler would accept this and convert the value on the call and return. Now, the compiler will give an error such as:

Error: The type of the actual argument differs from the type of the dummy argument. [3.0]
call sub(3.0)
---------^

This issue also arises for mismatches of integer and logical kinds. If your application took advantage of the earlier compiler's failure to diagnose this error, you can correct the problem by making sure that the argument is the correct kind. For constants, you can add the kind specifier suffix, such as 3.0_8 or 50_2. For constants or expressions, use the COMPLEX, INT, LOGICAL or COMPLEX intrinsics with the second KIND argument to convert the argument to the proper kind. For variables, you will need to correct the declaration of the variable to make sure that it matches the expected kind. The TRANSFER intrinsic can also be used to convert integer values, for example, TRANSFER(200,0_1) converts the value 200 as if it were an unsigned integer into an INTEGER(1) value.

EXTERNAL Actual Arguments in Generic Resolution

In earlier versions of the Intel Fortran Compiler, if a specific routine in a generic interface had a dummy argument declared as an interface to a subroutine, for example:

interface mygeneric
  subroutine specific1 (arg1, f)
    real(4), intent(in) :: arg1
    interface
      subroutine f (i)
        integer, intent(in) :: i
      end subroutine f
    end interface

  end subroutine specific1
end interface

the compiler would allow an actual argument declared as EXTERNAL to match the subroutine dummy argument. Interpretation 00101 to Fortran 95 specifies that this is incorrect behavior, and that EXTERNAL actual arguments do not match procedure arguments with an explicit interface. The compiler no longer matches such arguments and may give an error stating that no specific procedure was found for the generic reference.

The solution to this is to remove the EXTERNAL declaration and replace it with an explicit interface. This can be an INTERFACE block or it can be a module procedure.

Predefined Preprocessor Symbol for Intel EM64T

The compiler for Intel EM64T now defines the preprocessor symbol _M_X64 for use in conditionalizing applications for this platform.

Change in Behavior of FLUSH Library Routine

In versions 8.0 and 8.1 of the compiler, the FLUSH library routine from module IFPORT waited until the data was written to disk before returning control to the application. In version 9.0, FLUSH empties the internal buffers and waits for the operating system to acknowledge receipt of the data, but it does not wait for the disk to be updated, thus improving performance. If your application requires that the data be written to the physical disk file, use the COMMITQQ library routine instead.

ABORT Library Routine Now Exits with Non-Zero Status

A program whose execution is terminated by a call to the ABORT library routine, defined in module IFPORT), now exits with a status of 134. In previous releases, the exit status was set to zero.

EQUIVALENCEd variables cannot be DLLIMPORTed or DLLEXPORTed

The compiler now gives an error message if a variable given the DLLIMPORT or DLLEXPORT attribute is named in an EQUIVALENCE specification. This combination cannot be supported by the compiler, but previous versions did not give an error for it. Alternatives include a UNION inside a STRUCTURE or use of the TRANSFER intrinsic.

Buffering Now Supported for Direct-Access I/O

You may now enable buffering for units opened for direct-access I/O. Buffering causes the run-time library to read or write multiple records in a single disk operation. This can greatly improve run-time performance for applications which use direct-access I/O to access records in order, but may harm performance for applications which access records out-of-order. Buffering can be enabled or disabled in the same manner as for sequential I/O, including the BUFFERED keyword for OPEN, the /assume:buffered_io compile command option, and the FORT_BUFFERED environment variable. Buffering of direct-access I/O is not supported when the /fpscomp:general option is specified.

Constants Are Now Read-Only

Constants, including literals and named constants (PARAMETER), are now allocated in a memory section that is protected against write access. This means that if a constant is passed as an actual argument to a procedure and the procedure tries to modify the argument, an access violation will result. For example:

call sub (3)
...
subroutine sub (i)
i = i + 1 ! Will cause an access violation


The Fortran language prohibits changing the definition status of an argument associated with a constant or expression. If your application needs to do so, you can specify the /assume:noprotect_constants option. (In the visual development environment, select project property Fortran..Data..Constant Actual Arguments Can Be Changed..Yes.) This will instruct the compiler to create and pass a temporary copy of the constant actual argument. The called procedure can change this copy which will be discarded when the procedure exits.

Uninitialized Variable Checking Now Supported in All Contexts

As of version 9.0.030, uninitialized variable checking (/check:uninit) is supported for programs run in any context, not just when built against the debug libraries and run under the Visual Studio debugger, as was the case in earlier versions. Console applications will display the message in the console window, with traceback if /traceback was also specified. QuickWin and Windows applications will display the message in a message box. The message will be of the form:

forrtl: severe (193): Run-Time Check Failure. The variable 'TEST$J' is being used without being defined

The variable name may be displayed with an added prefix of the name of the program unit where the error occurred - TEST in this example.

Please note that uninitialized variable checking is currently limited to scalar, local variables. Arrays, COMMON variables and routine arguments are not checked.

Compiler Selection Option in Microsoft* Visual Studio*.NET* Development Environment

If you have both versions 8.1 and 9.0 of Intel Visual Fortran Compiler installed, only one of those may be integrated into the Microsoft Visual Studio.NET development envirronment. However, the version 9.0 integration adds a new option to allow selection of the 8.1 compiler binaries, include files and libraries while building a project. To select the 8.1 compiler, go to Tools..Options..Intel(R) Fortran..General and make your choice from the Selected Compiler Version control. Please also see the note below under Known Issues regarding the need to copy deftofd.exe to the 8.1 BIN folder

Rename of User-Defined Operators in USE (Fortran 2003 feature)

A rename clause on a USE statement may now also specify a defined operator. For example:

USE mymod, OPERATOR(.localop.) => OPERATOR(.moduleop.)

PROTECTED Attribute and Statement (Fortran 2003 feature)

The PROTECTED attribute restricts the use of module entities. Other than within the module within which the entity has been given the PROTECTED attribute. the following restrictions apply:

If an object has the PROTECTED attribute, all of its subobjects have the PROTECTED attribute.

INTENT Attribute for Pointer Objects (Fortran 2003 feature)

Pointer dummy arguments may now have the INTENT attribute specified. The INTENT attribute restricts how the association status of the pointer may change - it does not restrict changes to the target of the pointer.

MOVE_ALLOC Intrinsic Subroutine (Fortran 2003 feature)

The MOVE_ALLOC intrinsic subroutine moves an allocation from one allocatable object to another.

Syntax: CALL MOVE_ALLOC (FROM, TO)

Arguments:

FROM
May be of any type and rank and must be allocatable.
TO
Must be type compatible with FROM, have the same rank, and be allocatable.

If TO is currently allocated, it is deallocated. Then, if FROM is allocated, TO becomes allocated with the same bounds and value identical to that of FROM. Lastly, FROM is deallocated. If TO has the TARGET attribute, any pointer associated with FROM at the time of the call to MOVE_ALLOC is now associated with TO.

The implementation of MOVE_ALLOC is such that the internal descriptor contents are copied from FROM to TO, so that the storage pointed to is the same. The typical use of MOVE_ALLOC is to provide for an efficient implementation of reallocating an variable to a larger size without copying the data twice.

Fortran 2003 Feature Summary

The Intel Visual Fortran Compiler supports many features that are new to the latest revision of the Fortran standard, Fortran 2003. Additional Fortran 2003 features will appear in future versions. Fortran 2003 features supported by the current compiler include:

Intel® Array Visualizer

The following features have been added since the 3.0 release of Intel Array Visualizer:

The following features have been added since the 3.1 release of Intel Array Visualizer:

IMSL* Fortran Libraries 5.0 (Professional Edition Only)

The IMSL* Fortran Libraries 5.0, provided in Intel Visual Fortran Compiler Professional Edition, have been updated for this release to include corrections for reported problems. Libraries for Intel EM64T-based applications are now provided, and the cross-compiler for Itanium-based applications is now supported for use with the IMSL libraries. We strongly recommend that you rebuild, with the 9.0 compiler, applications that use the IMSL libraries to accommodate previous errors in external name decoration.

Please note the following changes:

Please refer to the section on using IMSL in the Using Libraries chapter of the Intel Fortran User Manual for additional information, including configuration for use on the command line and in the Microsoft IDE.

Change History

This section provides a summary of behavior changes in updates to 9.0. The version numbers here may not correspond to actual released versions - released versions with the indicated number or higher have the changes noted.

9.0.020
9.0.021
9.0.024
9.0.025
9.0.029
9.0.030

System Requirements

Processor Terminology

Intel compilers support three platforms: general combinations of processor and operating system type. This section explains the terms that Intel uses to describe the platforms in its documentation, installation procedures and support site.

IA-32
IA-32 (Intel Architecture, 32-bit) refers to systems based on 32-bit processors from the Intel Pentium® family, (for example, Intel® Core™, Pentium® 4, Pentium® D, Celeron® or Intel® Xeon®), or processors from other manufacturers supporting the same instruction set, running a 32-bit operating system.
EM64T
Intel® EM64T (Intel® Extended Memory 64 Technology) refers to systems based on IA-32 processors which have 64-bit architectural extensions, running a 64-bit operating system such as Microsoft* Windows* XP Professional x64 Edition or Microsoft Windows Server 2003 x64 Edition. Systems based on the AMD* Athlon64* and Opteron* processors running a 64-bit operating system are also supported by Intel compilers for EM64T-based applications.
Itanium®
Refers to systems based on the Intel Itanium® 2 processor running a 64-bit operating system.

Native and Cross-Platform Development

The term "native" refers to building an application on a platform type the same as the one on which it will be run, for example, building on IA-32 to run on IA-32. The term "cross-platform" or "cross-compilation" refers to building an application on a platform type different from the one on which it will be run, for example, building on IA-32 to run on Intel Itanium®. Not all combinations of cross-platform development are supported and some combinations may require installation of optional tools and libraries.

The following table describes the supported combinations of compilation host (system on which you build the application) and application target (system on which the application runs).

Host and Target Combinations
Host \ Target IA-32 Intel®
EM64T
Intel®
Itanium®
IA-32
Yes
Yes
Yes
Intel® EM64T
Yes
Yes
No
Intel® Itanium®
No
No
Yes

Minimum Hardware Requirements to Develop Applications

Software Requirements to Develop IA-32 Applications

Software Requirements to Develop Applications for Systems with Intel EM64T or AMD Opteron Processors

Software Requirements to Develop Itanium-based Applications

Requirements to Run Applications

Notes:

It is the responsibility of application developers to ensure that the machine instructions contained in the application are supported by the operating system and processor on which the application is to run.

Installation

Please see the separate Installation Guide for installation and configuration instructions.

Known Issues

Installation related limitations

Limitations on integration with Visual C++ .NET

2GB Static Code and Data Size Limit for Intel EM64T

The total size of static code and data in an executable program cannot exceed 2GB in Windows x64 Editions on Intel EM64T. This restriction comes from the design of the COFF object language for Windows and is not a compiler or processor limitation. Dynamically allocated data may exceed 2GB in size.

Link Error for Itanium-based Systems

When building for Itanium-based systems only, applications may fail to link with errors such as the following:

LIBC.lib(a_str.obj) : error LNK2001: unresolved external symbol __security_cookie
[...]
LIBC.lib(a_str.obj) : error LNK2001: unresolved external symbol __security_check_cookie
[...]

This problem is due to an inconsistency within some versions of the Microsoft Platform SDK. Intel is working with Microsoft to resolve this issue. To work around the problem, link your application in one of the following ways:

Limited Debug Information with Automatic CPU Dispatching (/Qax*)

Compilation using /Qax{W|N|B|P} results in two copies of generated code for each function: one for IA-32 generic code and one for CPU specific code. The symbol for each function then refers to an Auto CPU Dispatch routine that decides at run-time which one of the generated code sections to execute. Debugger breakpoints that are set on these functions by name cause the application to stop in the dispatch routine. This may cause unexpected behavior when debugging. This issue may be addressed in a future version of the Intel Debugger and Compilers.

Cannot Debug or View Traceback for IA-32 Programs Built with /Oy-

Compilation using /Oy- specifies that the IA-32 EBP register be used as a general purpose register, eliminating its use as a frame pointer. Debuggers and traceback handlers may not be able to properly unwind through a stack that contains a call to a function that is compiled in this manner.

POSIX* Library routine PXFGETPPID Not Supported on Windows NT 4.0

Applications which use the POSIX* library routine PXFGETPPID will not run on Windows NT 4.0. Windows 2000 or later is required for such applications.

Extra Floating Point Exception Visible When Debugging

On IA-32 systems, for programs compiled with the -fpe:0 option that encounter a floating point exception, one extra floating overflow exception will be raised deliberately by the Fortran runtime library to determine which version of the Microsoft libraries is linked to the user’s program.  This extra exception is raised only once per program process.  When in the debugger, users should not be alarmed to see an expected underflow exception followed by an unexpected overflow exception.

Technical Support

Your feedback is very important to us. To receive technical support for the tools provided in this product and technical information including FAQ's and product updates, you need to be registered for an IntelŪ Premier Support account on our secure web site, https://premier.intel.com. Please register at https://registrationcenter.intel.com/ .

Note: If your distributor provides technical support for this product, please contact them for support rather than Intel.

For information about the IntelŪ Visual Fortran Compiler's Users Forums, FAQs, tips and tricks, and other support information, please visit: http://support.intel.com/support/performancetools/fortran/windows/. For general support information please visit http://www.intel.com/software/products/support/.

Submitting Issues

Steps to submit an issue:

  1. Go to https://premier.intel.com/.
  2. Log in to the site. Note that your username and password are case-sensitive.
  3. Click on the "Go" button next to the "Product" drop-down list.
  4. Click on the "Submit Issue" link in the left navigation bar.
  5. Choose "Development Environment (tools,SDV,EAP)" from the "Product Type" drop-down list.
  6. If this is a software or license-related issue, choose "Intel(R) Fortran Compiler for Windows*" from the "Product Name" drop-down list.
  7. Enter your question and complete the fields in the windows that follow to successfully submit the issue.

Guidelines for problem report or product suggestion:

  1. Describe your difficulty or suggestion.
    For problem reports please be as specific as possible, so that we may reproduce the problem. For compiler problem reports, please include the compiler options and a small test case if possible.
  2. Describe your system configuration information.
    You can obtain the Package ID information as follows: Select Start..All Programs..Intel(R) Software Development Tools..Intel(R) Fortran Compiler 9.0..Build Environment for IA-32 Applications (substitute EM64T-based or Itanium(R)-based as applicable). Type the command:
        ifort /what
    and copy the "Package ID" (e.g. w_fc_c_9.0.xxx) from the output into the corresponding Intel® Premier Support field. Please include any other specific information that may be relevant to helping us to reproduce and address your concern.
  3. If you were not able to install the compiler or cannot get the Package ID, enter the filename you downloaded as the package ID.

Resolved Issues

Please review <package ID>_README.TXT (e.g. w_fc_c_9.0.xxx_README), available for download from IntelŪ Premier Support, https://premier.intel.com, to see which issues have been resolved in the latest version of the compiler.

Documentation

You can view the Intel compiler and related HTML-based documentation with a web browser that supports the Compiled HTML Help (.CHM) format, which provides full navigation, index look-up, search, and hyperlink capabilities. If your browser does not support opening .CHM files, you can open them directly by double-clicking on the file names in Windows Explorer in the Docs directory.

The documentation index is provided for easy access of all documents. The Document index is available from the IntelŪ Visual Fortran Compiler program folder and is located at: <install-dir>Compiler\Fortran\9.0\Docs\doc_index.htm. For this release, the online help has been reorganized as described in the doc_index.htm file and now includes a Getting Started guide as well as a separate Installation Guide. A training tutorial Enhancing Performance with the IntelŪ Compiler is also available from the IntelŪ Visual Fortran Compiler program folder. The IntelŪ Debugger Manual is available from the IntelŪ Debugger program folder.

Additional Information

Related Products and Services

Information on Intel software development products is available at http://www.intel.com/software/products.

Some of the related products include:

Disclaimer and Legal Information

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications.
Intel may make changes to specifications and product descriptions at any time, without notice.

Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.

The software described in this document may contain software defects which may cause the product to deviate from published specifications. Current characterized software defects are available on request.

BunnyPeople, Celeron, Centrino, Centrino logo, Chips, Dialogic, EtherExpress, ETOX, FlashFile, i386, i486, i960, iCOMP, InstantIP, Intel, Intel logo, Intel386, Intel486, Intel740, IntelDX2, IntelDX4, IntelSX2, Intel Core, Intel Inside, Intel Inside logo, Intel NetBurst, Intel NetMerge, Intel NetStructure, Intel SingleDriver, Intel SpeedStep, Intel StrataFlash, Intel Viiv, Intel XScale, IPLink, Itanium, MCS, MMX, MMX logo, Optimizer logo, OverDrive, Paragon, PDCharm, Pentium, Pentium II Xeon, Pentium III Xeon, Performance at Your Command, skoool, Sound Mark, The Computer Inside., The Journey Inside, VTune, Xeon, and Xircom are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

Microsoft, Windows, and the Windows logo are trademarks, or registered trademarks of Microsoft Corporation in the United States and/or other countries.

*Other names and brands may be claimed as the property of others.

Copyright © 2006, Intel Corporation.