Re: (Re)allocation of allocatable arrays on assignment - F2003

[Tobias Burnus <burnus at net-b dot de>]

 Dear Paul,

first, I think your work is awesome!

I will later try your patch - also with regards to performance. For the 
final patch, can you include a test case, which ensures that gfortran 
will not reallocate the memory if it is not needed? That's mandated by 
the standard if the allocatable has the TARGET attribute (and 
performance wise presumably makes always sense).

On 10/08/2010 05:21 PM, Paul Richard Thomas wrote:
> The most important input that I need from the world at large is how to
> minimize the impact on legacy code; ie. whether this should be the
> F2003 default.  My opinion is that it should be, even if this brings
> some penalty with it.  I have some ideas how to ameliorate this
> problem that appear in the TODOs

I also think that (re)allocate on assignment should be the default with 
all -std= but "f95", i.e. with f2003, f2008, gnu, and legacy. However, I 
think one should add a flag to disable the reallocation.

The reason I think that it should be the default: Fortran users 
(especially those grown up with Fortran 2003) expect that the 
reallocation happens. Thus, for code which most of the time uses 
(DE)ALLOCATE, but sometimes not, a disabled reallocate will cause 
surprising out-of-bound failures. Thus, in that sense being standard 
conform - regardless how slow the generated code is - makes sense. 
Especially, we would later have to change the default when more Fortran 
2003/2008 code gets written. But the same reason for not enabling it 
will still exist in, e.g., 5 years: legacy code (which won't compile 
with -std=f95). Thus, I think having forward looking default (enabling 
reallocate) while still making it possible (via a flag) to keep the old 
performance (and be it only for benchmarks*) seems to be the best choice.

(Note: For new code, one can use  "array(:,:) = " instead of "array = " 
to disable the (re)allocation checks in the performance critical parts 
of the program.)


Intel's ifort and Cray's ftn (crayftn) both have such a flag; both 
compilers default to the pre-F2003 behaviour. Though, at least in 
Intel's case, the (re)allocation is by default enabled for string length 
as they argue that that is a new Fortran 2003 feature.

 * * *

Intel has:

       -assume keyword
              Default:
[...]
              norealloc_lhs     The compiler uses  Fortran  95/90  rules
                                when interpreting assignment statements.
                                The left-hand  side  is  assumed  to  be
                                allocated with the correct shape to hold
                                the  right-hand  side.  If  it  is  not,
                                incorrect behavior will occur.

Cray has:

-d disable, -e enable/
/[...]
w

Enables support for automatic memory allocation for allocatable 
variables and arrays that are on the left hand side of intrinsic 
assignment statements.

Using this option may degrade runtime performance, even when automatic 
memory allocation is not needed. It can affect optimizations for a code 
region containing an assignment to allocatable variables or arrays; for 
example, by preventing loop fusion for multiple array syntax assignment 
statements with the same shape.

Default: disabled.

 * * *

Tobias

* I actually expect that most users will simply use '-march=native' 
together with '-O2' or '-Ofast' and possibly '-funroll-loops', '-flto' 
and '-fwhole-program'. One can do more tweaking such as using 
-fno-protect-parens, but I doubt that a normal user will do this. 
Frankly, I am already happy if they find out that "-march=native" 
exists. But presumably there are even users which