Mark Williamson wrote:
> Joe Krahn wrote:
>> Also, the Amber9Forum section on "automatic vs allocated arrays" is not
>> exactly right. First, the pointer array needs the SAVE attribute to
>> ensure that the allocation is saved between calls. Second, it is better
>> to use an allocatable array rather than a pointer array. Pointer arrays
>> can sometime be much slower because pointers can be aliased, making some
>> vectorizations unsafe. For a local pointer, the compiler may or may not
>> be smart enough to assume no aliasing. Also, allocatable arrays are
>> always initialized as unallocated, so there is no need for the
>> 'first_call' flag. This might simplify some of the start-up code to
>> avoid memory leaks with multiple calls to SANDER.
>
>
> Hi Joe,
>
> Relating to this point and eventually linking to the current gfortran -g
> bug discussion in another other thread. When I started working on the
> chamber code I hit an issue with allocatable arrays and gfortran 4.1.2.
>
> Basically, gfortran 4.1.2 would fail compiling a piece of code like this:
>
> cat hello.f95
> program main
>
> contains
>
> subroutine foo(x)
> integer, allocatable :: x(:)
> end subroutine foo
>
> end program main
>
> The error generated would be:
>
> integer, allocatable :: x(:)
> 1
> Error: In the selected standard, ALLOCATABLE attribute conflicts with
> DUMMY attribute at (1)
>
>
> These are the cvs logs that show where I "fixed" this issue in the
> chamber code:
>
>
> [mjw:chamber]$ cvs log psfprm.f
> ---snip---
> revision 10.16
> date: 2009/01/23 20:05:44; author: mjw; state: Exp; lines: +35 -35
> MJW: Attempt to translate a F2003-ism to F95 to avoid the following
> error with gfortran < 4.2
>
> gfortran -c -O3 -fno-second-underscore -ffree-form -o psfprm.o
> _psfprm.f
> In file _psfprm.f:2025
>
> a0,a1,a2,a3,a4,a5,a6,a7,a8
> 1
> Error: ALLOCATABLE attribute conflicts with DUMMY attribute at (1)
> --snip---
>
>
> and the actual code change:
>
> [mjw:chamber]$ cvs diff -r 10.16 -r 10.15 psfprm.f
> Index: psfprm.f
> ===================================================================
> RCS file: /home/amber_cvs/cvsroot/amber11/src/chamber/psfprm.f,v
> retrieving revision 10.16
> retrieving revision 10.15
> diff -r10.16 -r10.15
> 50c50
> < integer, pointer, dimension(:) :: iresid,ipres,iac,imove, &
> ---
> > integer, allocatable, dimension(:) :: iresid,ipres,iac,imove, &
> 59c59
>
> --etc---
>
> So, I changed the allocatable arrays to pointer arrays to avoid this
> error. However, this is the converse to what is being said above.
>
These are different issues. Declaring dummy arguments as allocatables is
not in Fortran90. You only need the argument to be allocatable if you
want to allocate it inside the subroutine and return the allocated
array. The original idea is that allocatable arrays are either globals,
or only used as temporary arrays inside procedures. This is because a
local allocatable array is automatically deallocated at the end of a
procedure.
So, allocatables are always better, but global allocatables need to be
accessed as globals and not dummy arguments to allocate them.
In general, pointers should only be used to point to memory, and not to
allocate it. The exception is that derived types cannot hold
allocatables until F2003, or with the TR-15581 extension, which should
not be used yet due to portability.
Maybe I should make a Wiki page explaining allocatable and pointer types?
Joe
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Apr 01 2009 - 01:09:02 PDT
