This is a computer translation of the original content. It is provided for general information only and should not be relied upon as complete or accurate.

Sorry, we can't translate this content right now, please try again later.

This document provides a summary of new and changed product features and includes notes about features and problems not described in the product documentation.

Please see the licenses included in the distribution as well as the Disclaimer and Legal Information section of these release notes for details. Please see the following links for information on this release of the Intel® Fortran Compiler 17.0.

Development of 64-bit applications, and those that offload work to Intel® Xeon Phi™ coprocessors, is supported on a 64-bit version of the OS only. Development of 32-bit applications is supported on a 64-bit version of the OS only.

Development for a 32-bit on a 64-bit host may require optional library components (ia32-libs, lib32gcc1, lib32stdc++6, libc6-dev-i386, gcc-multilib, g++-multilib) to be installed from your Linux distribution.

For the best experience, a multi-core or multi-processor system is recommended

For development of IA-32 or Intel® 64 architecture applications, one of the following Linux distributions (this is the list of distributions tested by Intel; other distributions may or may not work and are not recommended - please refer to Technical Support if you have questions):

Debian* 7.0, 8.0

Fedora* 24, 25

Red Hat Enterprise Linux* 6, 7

SuSE LINUX Enterprise Server* 11 (SP3, SP4),12

Ubuntu* 14.04 LTS, 15.10, 16.04 LTS

Intel® Cluster Ready

Linux Developer tools component installed, including gcc, g++ and related tools. (this is the list of component versions tested by Intel; other versions may or may not work and are not recommended - please refer to Technical Support if you have questions

gcc 4.3 to gcc 6.0

binutils 2.20 to binutils 2.26

Library libunwind.so is required in order to use the –traceback option. Some Linux distributions may require that it be obtained and installed separately.

Notes

The Intel® compilers are tested with a number of different Linux distributions, with different versions of gcc. Some Linux distributions may contain header files different from those we have tested, which may cause problems. The version of glibc you use must be consistent with the version of gcc in use. For best results, use only the gcc versions as supplied with distributions listed above.

Compiling very large source files (several thousands of lines) using advanced optimizations such as -O3, -ipo and -qopenmp, may require substantially larger amounts of RAM.

Some optimization options have restrictions regarding the processor type on which the application is run. Please see the documentation of these options for more information.

Intel® Manycore Platform Software Stack (Intel® MPSS)

The Intel® Manycore Platform Software Stack (Intel® MPSS) may be installed before or after installing the Intel® Fortran Compiler, if you will be developing applications that use Intel® Xeon™ Phi coprocessors..

Using the latest version of Intel® MPSS available is recommended. It is available from the Intel® Software Development Products Registration Center at http://registrationcenter.intel.com as part of your Intel® Parallel Studio XE for Linux* registration.

Refer to the Intel® MPSS documentation for the necessary steps to install the user space and kernel drivers.

Japanese Language Support

Intel® compilers optionally provide support for Japanese language users when the combined English-Japanese product is installed. Error messages, visual development environment dialogs and some documentation are provided in Japanese in addition to English. By default, the language of error messages and dialogs matches that of your operating system language selection. Japanese-language documentation can be found in the ja subdirectory for documentation.

Japanese language support is not provided with every update of the product.

Compatibility

In general, object code and modules compiled with earlier versions of Intel Fortran Compiler for Linux* (8.0 and later) may be used in a build with version 17. Exceptions include:

Sources that use the CLASS keyword to declare polymorphic variables and which were built with a compiler version earlier than 12.0 must be recompiled.

Objects built with the multi-file interprocedural optimization (-ipo) option must be recompiled with the current version.

Objects that use the REAL(16), REAL*16, COMPLEX(16) or COMPLEX*32 datatypes and which were compiled with versions earlier than 12.0 must be recompiled.

Objects built for the Intel® 64 architecture with a compiler version earlier than 10.0 and that have module variables must be recompiled. If non-Fortran sources reference these variables, the external names may need to be changed to remove an incorrect leading underscore.

Modules that specified an ATTRIBUTES ALIGN directive outside of a derived type and were compiled with versions earlier than 11.0 must be recompiled. The compiler will notify you if this issue is encountered.

Modules that specified an ATTRIBUTES ALIGN directive inside a derived type declaration cannot be used by compilers older than 13.0.1.

The implementation of the Fortran 2008 submodules feature required extensive changes to the internal format of binary .mod files. Therefore module files created by the version 16.0 or newer Fortran compiler cannot be used with version 15.0 or older Fortran compilers.

Stack Alignment Change for REAL(16) and COMPLEX(16) Datatypes

In versions prior to 12.0, when a REAL(16) or COMPLEX(16) (REAL*16 or COMPLEX*32) item was passed by value, the stack address was aligned at 4 bytes. For improved performance, the version 12 and later compilers align such items at 16 bytes and expects received arguments to be aligned on 16-byte boundaries. This change is also compatible with gcc.

This change primarily affects compiler-generated calls to library routines that do computations on REAL(16) values, including intrinsics. If you have code compiled with earlier versions and link it with the version 12 libraries, or have an application linked to the shared version of the Intel run-time libraries, it may give incorrect results.

In order to avoid errors, you must recompile all Fortran sources that use the REAL(16) and COMPLEX(16) datatypes if they were compiled by compiler versions earlier than 12.0.

New and Changed Features

Some language features may not yet be described in the compiler documentation. Please refer to the Fortran 2008 Standard (PDF) and the proposed draft Fortran 2015 Standard (PDF) if necessary.

Features from Fortran 2008

Type statement for intrinsic types

Pointer initialization

Implied-shape array

Extend EXIT statement to more construct names

Support BIND(C) in internal procedures

Change of Default in Intrinsic Assignment to Allocatable Arrays (17.0)

In previous releases, the compiler's default for intrinsic assignment to allocatable arrays was to assume that the array being assigned to was already allocated to the same shape as the value. In order to get the Fortran 2003 behavior of automatically (re)allocating the array if the shapes did not match you were required to specify the -assume realloc_lhs compiler option (included in -standard-semantics.)

In version 17.0 of the compiler, the default has changed to match the Fortran 2003 standard so that allocatable arrays are automatically (re)allocated on intrinsic assignment as needed. This may have a small impact on performance. If you want to revert to the older behavior, specify -assume norealloc_lhs or the new -nostandard-realloc-lhs compiler option.

Changes in Behavior of Mixed Logical/Numeric Operations (17.0)

The Fortran standard prohibits assignments and operations that mix logical and numeric (integer/real/complex) data types. As an extension to the standard, Intel Fortran permits this mixing, but the rules for how it works were not well documented and were inconsistently implemented depending on the context.

As of version 17.0, the compiler’s implementation of mixed logical-numeric operations has changed to be consistent and well-specified. However, in some cases the new behavior is different from what previous versions implemented and may change results in programs that assumed that the previous behavior was correct.

The version 17.0 behavior is as follows:

If a logical value is used in a numeric context, true values convert to integer -1 or +1, depending on the setting of the “fpscomp logicals” compiler option; false values convert to integer zero.

If a numeric value is used in a logical context, it is first converted to integer if necessary. The setting of the compiler “fpscomp logicals” option determines how the integer value is interpreted. When “nologicals” is in effect, odd values are true and even values are false. When “logicals” is in effect, non-zero values are true and zero values are false.

If a numeric value is assigned to a logical variable, the value is converted to .TRUE. or .FALSE. according to the setting of “fpscomp logicals” and the new logical value assigned. In some cases in previous versions, the binary value might have been copied directly without conversion.

If a logical value is assigned to a numeric variable, it is first converted to integer as described above and then the normal rules of intrinsic assignment are carried out.

Note that the Intel Fortran compiler default is “fpscomp nologicals”, but that the “standard-semantics” option sets “fpscomp logicals”.

If you want to know if your program is affected by this extension, build with standards warnings enabled (/stand). If you wish to revert to the old behavior, specify -assume old_logical_assign.

Change in Default Offload Treatment of Local Scalars with OpenMP* 4.5

The addition of support for the OpenMP* 4.5 clause DEFAULTMAP (TOFROM:SCALAR) changed the default treatment of local scalar variables. In the previous release local scalars were offloaded by default. In 17.0, local scalars are not mapped and instead have an implicit attribute of FIRSTPRIVATE. Offload of local scalars in 17.0 requires using DEFAULTMAP (TOFROM:SCALAR). See the Intel® Fortran Compiler User’s Guide for more details.

OpenMP* monitor thread

As of version 17.0.1, the OpenMP* monitor thread (i.e. helper thread) is not created.

Features from OpenMP*

The following directives, clauses and procedures, from OpenMP 4.0 and OpenMP 4.5, are supported by the compiler.

For more information, see the compiler documentation or the link to the OpenMP Specification above.

Directives from OpenMP 4.5:

TARGET ENTER DATA

TARGET EXIT DATA

TASKLOOP

Clauses:

DEPEND on OMP TARGET and OMP TARGET UPDATE directives

NOWAIT on OMP TARGET and OMP TARGET UPDATE directives

SIMDLEN on OMP SIMD directive

SIMD on OMP ORDERED directive

PROCESSOR(cpuid) on OMP DECLARE SIMD (proc-name) directive

DEFAULTMAP (TOFROM:SCALAR) on OMP TARGET

Added processor clause to OMP DECLARE SIMD

The Intel® Fortran Compiler 17.0 includes an extension to OMP DECLARE SIMD which will allow programmers to use YMM/ZMM registers with OpenMP SIMD. The clause PROCESSOR(cpuid) will tell the compiler to create a vector version of a routine for the specified processor. See the Intel® Fortran Compiler User’s Guide for more details.

SIMD and NONMONOTONIC modifiers for !$OMP DO SCHEDULE clause

The Intel® Fortran Compiler 17.0 includes new SIMD and NONMONOTONIC modifiers extensions to OMP DO SCHEDULE clause to enhance user control of how iterations of the DO loop are divided among threads of the team. See the Intel® Fortran Compiler User’s Guide for more details.

Support for taskloop and do across loop as described in the OpenMP* 4.5

The Intel® Fortran Compiler 17.0 adds support for new loop construct for parallelizing for/do loops. “taskloop” is similar to cilkfor loop, enables the dynamic divide-and-conquer loop partitioning under Intel tasking execution model. “doacross” enables the parallelization of loops with loop-carried dependency.

New Intel® Xeon Phi™ offload features

OpenMP* 4.5 clause changes

for combined or composite constructs, the if clause now supports a directive name modifier:

if([directive-name-modifier :] scalar-logical-expression) the if clause only applies to the semantics of the construct named by directive-name-modifier if specified; otherwise it applies to all constructs to which an if clause can apply. Example: !$omp target parallel for if(target : do_offload_compute)

use_device_ptr(list) clause now implemented for !$omp target data

is_device_ptr(list) clause now implemented for !$omp target

Support for combined target constructs:

!$omp target parallel

!$omp target parallel for

!$omp target simd

!$omp target parallel for simd

New modifiers for omp declare simd linear clause

The linear clause on omp declare simd declarative directive is extended with new modifiers:

linear (linear-list [ : linear-step] )
where linear-list is one of the following:list
where modifier (list)modifier is one of the following:refvaluval

All list items must be dummy arguments of the function that will be invoked concurrently on each SIMD lane.

If no modifier is specified or if the val or uval modifier is specified, the value of each list item on each lane corresponds to the value of the list item upon entry to the function plus the logical number of the lane times linear-step.

If the uval modifier is specified, each invocation uses the same storage location for each SIMD lane; this storage location is updated with the final value of the logically last lane.

If the ref modifier is specified, the storage location of each list item on each lane corresponds to an array at the storage location upon entry to the function indexed
by the logical number of the lane times linear-step.

New and Changed Directives

ATTRIBUTES code_align(n)

As of compiler version 17.0, the ATTRIBUTES code_align(n) directive may be specified to request code alignment for a function. 'n' specifies the number of bytes for the minimum alignment boundary. It must be a power of 2 between 1 and 4096, such as 1, 2, 4, 8, 16, 32, 64, 128, and so on. n = 1 does no alignment. n must appear.

New -[no]standard-realloc-lhs Compiler Option

New -qopt-zmm-usage option

You can tune the zmm code generation done by the compiler with the new additional option -qopt-zmm-usage:low|high. The argument value of low provides a smooth transition experience from Intel® Advanced Vector Extensions 2 (Intel® AVX2) ISA to Intel® Advanced Vector Extensions 512 (Intel® AVX-512) ISA on a Skylake server microarchitecture target, such as for enterprise applications. Tuning for ZMM instruction use via explicit vector syntax such as #pragma omp simd simdlen() is recommended. The argument value of high is recommended for applications, such as HPC codes, that are bounded by vector computation to achieve more compute per instruction through use of the wider vector operations. The default value is low for Skylake server microarchitecture-family compilation targets and high for combined compilation targets.

Known Issues

The following uses of length type parameters in parameterized derived types (PDTs) are not yet fully implemented:

PDT parameter constants with length type parameters

%RE and %IM are not yet implemented

Certain uses of OMP THREADPRIVATE with COMMON block name not diagnosed per OpenMP* 4.5 rules

The OpenMP* 4.5 rules states that if a threadprivate directive specifying a common block name appears in one program unit, then such a directive must also appear in every other program unit that contains a COMMON statement specifying the same name. It must appear after the last such COMMON statement in the program unit. The Intel Fortran compiler does not properly diagnose this.

For example, the following program does not conform to the OpenMP* 4.5 specification and ifort does not diagnose and issue an error for the COMMON statements following the OMP THREADPRIVATE statement according to the rule above.

Fortran 2008 and Fortran 2015 Feature Summary

The Intel® Fortran Compiler also supports many features from the Fortran 2008 standard as well as Features from the proposed draft Fortran 2015 standard. Additional features will be supported in future releases. Fortran 2008 features supported by the current version include:

An OPTIONAL dummy argument that does not have the ALLOCATABLE or POINTER attribute, and which corresponds to an actual argument that: has the ALLOCATABLE attribute and is not allocated, or has the POINTER attribute and is disassociated, or is a reference to the NULL() intrinsic function, is considered not present

A dummy argument that is a procedure pointer may be associated with an actual argument that is a valid target for the dummy pointer, or is a reference to the intrinsic function NULL. If the actual argument is not a pointer, the dummy argument shall have the INTENT(IN) attribute.

BLOCK construct

intrinsic subroutine EXECUTE_COMMAND_LINE

Submodules

IMPURE

Type statement for intrinsic types

Pointer initialization

Implied-shape array

Extend EXIT statement to more construct names

Support BIND(C) in internal procedures

Proposed draft Fortran 2015 features supported by the current version include:

Support for all features from “Technical Specification 29113 Further Interoperability with C”, planned for inclusion in Fortran 2015. These include:

Assumed type (TYPE(*))

Assumed rank (DIMENSION(..))

relaxed restrictions on interoperable dummy arguments

ISO_Fortran_binding.H C include file for use by C code manipulating “C descriptors” used by Fortran

Disclaimer and Legal Information

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL(R) 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. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.

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 information here is subject to change without notice. Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.