Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Why is Standard Fortran not Standard Default behavior in Intel Compiler?

DataScientist
Valued Contributor I
832 Views

I have been wasting time for hours trying to understand why my code does not work, the way it should as the Fortran standard says. and finally I realized Intel Fortran compiler does not provide automatic reallocation by default, as it was introduced in Fortran 2003 Standard. According to this page:

https://software.intel.com/en-us/articles/error-variable-not-allocated-assume-realloc_lhs

one has to use the compilation flag /assume:realloc_lhs to get the "default" behavior as one should in modern Fortran. Why is there so much drag to follow the new Fortran standards? It is now a decade and half since this feature was introduced and yet one has to explicitly request the compiler to recognize the new Fortran stanard. Thanks for any reasonable explanation, and permanent fix to this problem, if there is any.

I am using:  Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

 

0 Kudos
8 Replies
andrew_4619
Honored Contributor II
832 Views

If you have standards checking (/stand) to f03 or higher than you get  /assume:realloc_lhs automatically I believe. Ifort does it this wway as otherwise old code that conformed to f95 would/could break.

0 Kudos
mecej4
Honored Contributor III
832 Views

If you use a more recent compiler, such as the current 17.0.4, /assume:realloc_lhs is the default. Earlier versions did what you described, and I remember reading discussions of what the default should be.

Please see https://software.intel.com/en-us/node/678232 .

0 Kudos
DataScientist
Valued Contributor I
832 Views

Thank you for your answers. I think this could also explain the random behaviors that I have seen on different devices with different Intel compiler versions.

0 Kudos
IanH
Honored Contributor II
832 Views

The flag you need to use is /standard-semantics. Use it, always.

The Fortran 2003 behaviour does not break conforming Fortran 95 programs, but it may have a slight performance impact.

0 Kudos
DataScientist
Valued Contributor I
832 Views

Thank you Ian. Is the performance hit you mentioned specific to parts of the codes that use the new >2003 standard features, or is it broader? For example, if I compile a F90 code with F03 syntax enabled, would it perform worse than when F03 syntax is disabled? My own naive answer would be "no".

0 Kudos
JVanB
Valued Contributor II
832 Views

/standard-semantics definitely does break some f95-conforming programs, but usually this is due to a change from one valid implementation choice to another. You have to get creative to compose a program that is guaranteed to behave differently between f95 and f2003.

 

0 Kudos
TimP
Honored Contributor III
832 Views
In a few isolated cases, performance of f2003 compliant compilation is well below f95. One such is vectorizable sum and dot product reduction.
0 Kudos
Steve_Lionel
Honored Contributor III
832 Views

andrew_4619 wrote:

If you have standards checking (/stand) to f03 or higher than you get  /assume:realloc_lhs automatically I believe. Ifort does it this wway as otherwise old code that conformed to f95 would/could break.

/stand does not affect this. You are correct that defaulting to current standard behavior across the board would break many existing programs. All of these cases are where earlier standards did not specify behavior and left it up to implementations. Over the years, The DEC/Compaq/Intel compilers did change defaults where it could without breaking many programs or severely impacting performance. 

0 Kudos
Reply