ALLOCATABLE ARRAY - Difference between ifort and gfortran?

[BRAHIM__ADJEROUD]

Hello, I have development issues whether on which computers I'm running my code. My two kind of computer are :
-    Computing Center (Intel Fortran, version compiler is 18.0.1.163)
-    Local Debian (GNU Fortran version is 4.9.2 (Debian 4.9.2-10) of 2014)
 
My code developed under gfortran is not executable under IFORT, and I would like to know the origin of this problem:
- Is this due to a standard Fortran problem (F90? F95? F2003? F2008?)
- Is it due to differences between Ifort and Gfortran standards?
 
Here's how my errors are  manifesting on ALLOCATABLE ARRAY:
 
First difference:
When an array is "ALLOCATABLE", GFORTRAN will allow allocation and initialization in one step, as in the following example:
 

INTEGER, DIMENSION (:), ALLOCATABLE :: MAT_I_1
MAT_I_1 = (/ (i, i = 1.10) /)

 
IFORT will require two step and that the allocation be prior to initialization:

INTEGER, DIMENSION (:), ALLOCATABLE :: MAT_I_1
ALLOCATE (MAT_I_1 (10))
MAT_I_1 = (/ (i, i = 1.10) /)

 
Second difference:
GFORTRAN will allow table size changes in one operation:

MAT_I_1 = MAT_I_1 = (/ (i, i = 3,8) /)

 
IFORT will require passing through an intermediate table:

ALLOCATE (TEMP_I (10))
TEMP_I = MAT_I_1
 
DEALLOCATE (MAT_I_1)
ALLOCATE (MAT_I_1 (6))
 
MAT_I_1 = TEMP_I ((/ (i, i = 3,8) /))
DEALLOCATE (TEMP_I)

 
Do you know more about those  small differences?
Sincerely
WireWith

[BRAHIM__ADJEROUD]

Here two fortran files to illustrate my issue.
First one ( ESSAI_TABLEAU.f ) run on both of my device, whether with ifort and gfortran,
(for exemple, this fortran file could be compiled with the command :
ifort ESSAI_TABLEAU.f -o ESSAI_TABLEAU
or
gfortran ESSAI_TABLEAU.f -o ESSAI_TABLEAU )

Second one (ESSAI_TABLEAU_GFORTRAN.f could only be compiled with gfortran,
(for exemple, this fortran file could be compiled with the command :
gfortran ESSAI_TABLEAU_GFORTRAN.f -o ESSAI_TABLEAU_GFORTRAN )

Does anyone could have an idea about my issue?
Sincerely.

[mecej4]

Please check if you are using compiler options that are comparable. I tried both your source files with IFort 18.0.1 on Windows 64, and the compiler processed them with no error messages.

[BRAHIM__ADJEROUD]

And could you please run the ESSAI_TABLEAU_GFORTRAN executable to see if you have no issue ?

here's mine, where I use this compilation command, :
ifort -check all -traceback ESSAI_TABLEAU_GFORTRAN.f -o ESSAI_TABLEAU_GFORTRAN

and then run ESSAI_TABLEAU_GFORTRAN,
I have the following issue :
forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable MAT_I_1 when it is not allocated

And I have no clue on why my work work perfectly on DEBIAN GNU FORTRAN but not on my brand new 18.0.1.163 IFORT !
(Is it possible that my computation center IFORT was humanly limited to f95 ?!)

Sincerely.

[mecej4 · Accepted solution]

Some time ago, at least with the Windows version, Ifort required /assume:realloc_lhs to obtain the behavior that your program requires. Currently, that is the default.

Earlier, I had not used /check:all. I did now, and I see no change. At least, this establishes that the bug that you encountered in the Linux version of Ifort 18.0.1 is not exhibited by the Windows version. I shortened the file name, but did not change the contents.

S:\LANG>ifort /check:all essai.f
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.1.156 Build 20171018
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:essai.exe
-subsystem:console
-incremental:no
essai.obj

S:\LANG>essai
 --------------
 ESSAI_TABLEAU_DEBUT
 MAT_I_1           1           2           3           4           5           6
           7           8           9          10
 MAT_I_2           1           2           3           4           5           6
           7           8           9          10
 MAT_I_3           1           2           3           4           5           6
           7           8           9          10
 ESSAI_TABLEAU_FIN
 --------------
 MAT_I_1           3           4           5           6           7           8
 MAT_I_2           3           4           5           6           7           8
 MAT_I_3           3           4           5           6           7           8

S:\LANG>findstr /i gfort essai.f
      PROGRAM ESSAI_TABLEAU_GFORTRAN
      END PROGRAM ESSAI_TABLEAU_GFORTRAN

S:\LANG>

If I explicitly specify /nostandard-realloc-lhs, I obtain:

forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable MAT_I_1 when it is not allocated

Image              PC                Routine            Line        Source
libifcoremd.dll    00007FF874503E07  Unknown               Unknown  Unknown
essai.exe          00007FF67D6310B4  MAIN__                     17  essai.f

I suggest that you explicitly specify -assume realloc_lhs on the remote Linux server. They may have placed the option -assume norealloc_lhs in the Ifort cfg file, since realloc_lhs may be seen as prone to causing slightly lower performance in the a.outs that are produced.

[BRAHIM__ADJEROUD]

Thank you very much for your very precise answer.
The use of the "-assume realloc_lhs" option allows me to have a similar behavior regardless on which computer I execute my job.

Sincerely.

[Steve_Lionel]

You should not need that option with the 18.0 compiler (nor 17.0).

[mecej4]

Steve Lionel (Ret.) wrote:
You should not need that option with the 18.0 compiler (nor 17.0).

He stated that their computer center has 18.0.1.163 on the Linux server; he has only Gfortran on his PC. That is why I guessed that they may have set up -norealloc_lhs on the server's ifort.cfg. Perhaps he should take this matter up with the server admins.

[Steve_Lionel]

That would be a very strange thing to do. Or it may be that he isn't actually using 18.0 on the server. It would be worth tracking down.

[BRAHIM__ADJEROUD]

My bad ! I'm actually using the intel/14.0.3.174 on my server.
I could use the 18.0.1.163 IFORT version, but it's not the default compiler.
By using the following commande

ifort -help

I can find in the help file the following option :

-standard-semantics
          sets assume keywords to conform to the semantics of the
          Fortran standard.  May result in performance loss.
          assume keywords set by -standard-semantics:
            byterecl, fpe_summary, minus0, noold_maxminloc,
            noold_unit_star, noold_xor, protect_parens, realloc_lhs,
            std_intent_in, std_mod_proc_name, std_minus0_rounding,
            std_value,noold_ldout_format
          also sets -fpscomp logicals

That lead me to thing that the default fortran used by IFORT is not conform to the semantics of the Fortran standard.

My server admin told me that only the following options are actually used on the Computing Center
* -sox
* -fp-speculation=safe
* -ftz
* -fp-model source
* -O2 ou -O3

Sincerely
WireWith

[Steve_Lionel]

Ok, that makes sense. The default changed in 17.0.

Yes, some of the Intel compiler behavior doesn't match the current standard. In some cases, doing so would break existing programs or would result in much slower code. -standard-semantics gets you the current standard behavior, but it helps to know what that means. See the "Additional Information" section of https://software.intel.com/en-us/articles/intel-fortran-compiler-support-for-fortran-language-standards/

[BRAHIM__ADJEROUD]

Hello again !

Here is a summary of Fortran standards.

Fortran 90 (ISO / IEC 1539: 1991) - Major Version
Fortran 95 (ISO / IEC 1539-1: 1997) - Minor version (evolution from F90)
Fortran 2003 (ISO / IEC 1539-1: 2004) - Major Version
Fortran 2008 (ISO / IEC 1539-1: 2010) - Minor version (evolution from F2003)

I've read the following article :

https://software.intel.com/en-us/articles/intel-fortran-compiler-support-for-fortran-language-standards

I was not able to understand if IFORT 14.0.3.174 was completely compliant (using the -standard-semantics option) to the Fortran 2008 or Fortran 2003 standard.

I may understand that no. IFORT 14.0.3.174 is only compliant with Fortran 2003.

Is anyone have a source ? Or some kind of information ??

Thank you all.

[Steve_Lionel]

There's two different things here.

1) Does a particular version of the compiler support 100% of the features in a given standard

2) Do the default behaviors of the compiler match what the standard says?

The particular behavior you are interested in was new in Fortran 2003. It was supported as far back as Compaq Visual Fortran 6.6C, but not by default. The reason it wasn't the default is that earlier standards required that the variable being assigned to be already allocated to the proper shape, and the added checking would impose a performance penalty that was not desirable. You could get the F2003 semantics with an option; there were other industry compilers that did something similar.

Over the years, more programmers relied on the new behavior and other compilers shifted their defaults to support the automatic reallocation. In reflection of that reality, the Intel compiler also changed its default in the 17.0 version. That said, there remain some Intel compiler default behaviors that don't match the standard - that's what -standard-semantics is for, a one-stop way of saying "please give me the behaviors of the standard." Changing those by default would break thousands of existing applications and that would be unacceptable.

The 17.0 compiler supports all the features of Fortran 2008 (and some of Fortran 2018).