forums.silverfrost.com

[PaulLaidler]

The next release will include a new FTN95 command line option /ALLOW_AOA. This will activate the Fortran 2003 feature that permits the assignment of an ALLOCATABLE object without a prior ALLOCATE. By default, ALLOW_AOA will be set false and this is a change from existing versions of FTN95.

This means that use of "allocate on assignment" will in future require the addition of this option to the command or that FTN95 be configured (via /CONFIG) to make this the default.

When allocating an array via an ALLOCATE statement, the lower bounds can be prescribed or allowed to take a default value of one. When re-allocated via "allocate on assigment" the lower bounds cannot be prescribed and must have their default value.

This means that the compiler must plant code for every potential "allocate on assignment" in order, first to test if the array has been allocated and (if it has) if its shape is different from that of the source array. A re-allocate must only be perfomed when there is a change of shape. In other words, "allocate on assigment" incurs a significant overhead. Similar considerations apply for other objects such as allocatable CHARACTER variables.

The new option gives the user control over this overhead and protects legacy code from any adverse impact.

[JohnCampbell]

Paul,

Thanks for this addition, as it is an area of uncertainty for me when using allocatable arrays in F03+ code.

My apologies but I am not sure if this is the option I am wanting, as I am probably wanting to write standard complying code.

What I am wanting is a WARNING option that (at compile time) notifies me when any auto reallocate is identified by the compiler.
I can then use this to investigate if this will do what I was expecting or wanted.
At the moment I am uncertain that I might miss when any auto reallocate is occurring.

Do you have any guidance of how to avoid re-allocate in standard conforming code? Could this include using array sections, rather than the full allocatable array name ?

I have not thought of the issues related to lower bounds, but they look to be worth reviewing if non default lower bounds are being coded.