Describe -assume realloc_lhs

[Germán]

Will somebody be kind enough to describe what it is that the subject option makes possible? 

[Steve_Lionel]

Before Fortran 2003, an assignment to an allocatable array required that the thing you're assigning had the exact same shape. Fortran 2003 added the feature that if the shapes don't match, the old array is deallocated and then reallocated to the new shape.

This required extra code to compare the shapes, and some compilers at the time (including Intel) didn't want to impose that burden on programs that had been written to F90/F95. So, the default behavior was to NOT do the check/reallocate and the option was added to enable that behavior. This was included in the -standard-semantics option as well.

Fast forward a few years, and more and more programmers relied on the F2003 reallocation feature, so sometime around the 16.0 timeframe (I forget exactly), Intel changed the default to do the reallocate check. -assume realloc_lhs was no longer needed, but you could turn it off if you wanted.

I'll note that for deferred-length allocatable character assignments, which were new in F2003, this option did not apply and you always got the F03 behavior (of reallocating if the lengths were different.)

[Germán]

Thank you very much for all that.

Also, it seems to explain my troubles.  I received code from a University that is presumably running fine; when I build it, it does not...apparently, they are compiling with 2019 and I with 2016.

While it seems that I can replicate 2019 behavior with 2016 and "-assume realloc_lhs", it seems to be behavior that I don't particularly like...I don't know the correct answer, but I see numbers  E+27...can't be right.  I am thinking the operation is getting corrupted; I am thinking they are misusing/abusing the default "realloc_lhs" behavior...after all, it is called "re-alloc", which I guess it assumes that something was allocated in the first place...but the student does not seem to be allocating not even once before first assignment. 

Anyway, I guess I need to continue testing building the various options and compare. 

Thanks again.

s what I seem to be witnessing in regards to compiling with 2016u4 vs. 2019u5

I myself have used Fortran since 66 and have not fully caught up to all new bells and whistles, and, I just received some code with 

[Germán]

Oops...left some residual text at the bottom of my previous message, I guess there is no way to edit a posted message? Oh well. 

[FortranFan]

German wrote:
Will somebody be kind enough to describe what it is that the subject option makes possible? 

Hopefully one of the Intel "writers" who work with the Intel Fortran team will chime in with a succinct yet comprehensive description for you based on their writing experience.

Nonetheless, considering the fact the topic in question pertains to Fortran 2003 standard published nearly 17 years ago and following which there have 2 other standard revisions and if you remain interested in Fortran after this,  I will suggest you refer to the current Fortran standard and other Fortran study material (e.g., books) to pursue standard-conforming Fortran code.  And note -assume realloc_lhs is part of standard-conforming aspect that is also related to -standard-semantics.

And here's an example you can try out to understand the implications:

   integer, allocatable :: x(:)
   allocate( x(2), source=0 )
   print *, "Following ALLOCATE, shape(x) = ", shape(x)
   print *, "x = ", x
   x = [ 1, 2, 3 ] !<-- NOTE: if expr on RHS has different shape, the standard states
                   ! the variable on LHS can get unallocated and reallocated
   print *, "After assignment: shape(x) = ", shape(x)
   print *, "x = ", x
end

The above example with -assume realloc_lhs:

C:\Temp>ifort /assume:realloc_lhs a.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1.2 Build 20201208_000000
Copyright (C) 1985-2020 Intel Corporation.  All rights reserved.

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

-out:a.exe
-subsystem:console
a.obj

C:\Temp>a.exe
 Following ALLOCATE, shape(x) =            2
 x =            0           0
 After assignment: shape(x) =            3
 x =            1           2           3

The same example with -assume norealloc_lhs:

C:\Temp>ifort /assume:norealloc_lhs a.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1.2 Build 20201208_000000
Copyright (C) 1985-2020 Intel Corporation.  All rights reserved.

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

-out:a.exe
-subsystem:console
a.obj

C:\Temp>a.exe
 Following ALLOCATE, shape(x) =            2
 x =            0           0
 After assignment: shape(x) =            2
 x =            1           2

[Steve_Lionel]

The option may be called "realloc_lhs" but this also covers the case where the variable being assigned to is not already allocated. Here is the way the standard describes it:

3 If the variable is an unallocated allocatable array, expr shall have the same rank. If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, any corresponding length type parameter values of the variable and expr differ, or the variable is polymorphic and the dynamic type or any corresponding kind type parameter values of the variable and expr differ. If the variable is or becomes an unallocated allocatable variable, it is then allocated with
 • the same dynamic type and kind type parameter values as expr if the variable is polymorphic,
 • each deferred type parameter equal to the corresponding type parameter of expr,
 • the same bounds as before if the variable is an array and expr is scalar, and
 • the shape of expr with each lower bound equal to the corresponding element of LBOUND (expr) if expr is an array.

[Germán]

Steve:

Again, thanks for the detailed description.  It sure looks dangerously powerful...something that could hide away some undesired behavior; but, maybe it's just me. 

FortranFan:

You said:
Nonetheless, considering the fact the topic in question pertains to Fortran 2003 standard published nearly 17 years ago and following which there have 2 other standard revisions and if you remain interested in Fortran after this,  I will suggest you refer to the current Fortran standard and other Fortran study material

You say that as if 17 was a long time, after all Fortran 77 was the work horse for 20+ years for many of us; and, now, Fortran 90/95, too, continues to be used for another 20 years. 

So, forgive me for not keeping up with the latest standards; to be honest, I took a peek at what's beyond 90/95 and it scared me a bit...it sure looks like Fortran is no longer that easy to learn, starting to include some convoluted constructs, a gamma of declaration attributes,  object orientation, etc. ...actually, seeing all this sadden me too.

Anyway, thank you very much for your post and the examples.  I now understand the "new" behavior.

Thanks.