Home > Archive > Fortran > June 2007 > lahey's deallocation warning - something to worry about?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
lahey's deallocation warning - something to worry about?
|
|
|
| If I pass the following program to the online Lahey Fortran Source
Check, I receive a warning (actually an information item):
program earth
use my_mod
implicit none
integer,parameter :: n=3
real(kind=8) :: a(n)
integer :: i
do i=1,n
a(i) = i*1.d0
enddo
write(*,*) a
a = modify(a)
write(*,*) a
end program earth
--------------------------------------------------------
module my_mod
contains
function modify(arr) result(res)
implicit none
real(kind=8),intent(in) :: arr(:)
real(kind=8),dimension(:),allocatable :: res
allocate(res(size(arr)))
res = arr*2.d0
end function modify
end module my_mod
-----------------------------------------
The warning I get is:
Compiling program unit my_mod at line 1:
Module subprogram name(modify)
2064-I: "MY_MOD.F90", line 11: If local allocatable array 'res' is
currently allocated when procedure exited by execution of a RETURN or
END statement, it is not deallocated.
Encountered 0 errors, 0 warnings, 1 information in file MY_MOD.F90.
------------------------------------------
What is happening here? I understand that the function result must be
around when it is assigned to 'a' in the main program. But after this
assignment, what is happening to the allocated memory. Is it freed, or
not? Is it something to worry about?
Arno
| |
| Tim Prince 2007-06-25, 10:07 pm |
| Arno wrote:
> If I pass the following program to the online Lahey Fortran Source
> Check, I receive a warning (actually an information item):
>
> program earth
>
> use my_mod
>
> implicit none
>
> integer,parameter :: n=3
> real(kind=8) :: a(n)
> integer :: i
>
> do i=1,n
> a(i) = i*1.d0
> enddo
>
> write(*,*) a
>
> a = modify(a)
>
> write(*,*) a
>
> end program earth
>
> --------------------------------------------------------
>
> module my_mod
>
> contains
>
> function modify(arr) result(res)
>
> implicit none
>
> real(kind=8),intent(in) :: arr(:)
> real(kind=8),dimension(:),allocatable :: res
>
> allocate(res(size(arr)))
> res = arr*2.d0
>
> end function modify
>
> end module my_mod
>
> -----------------------------------------
>
> The warning I get is:
>
> Compiling program unit my_mod at line 1:
> Module subprogram name(modify)
> 2064-I: "MY_MOD.F90", line 11: If local allocatable array 'res' is
> currently allocated when procedure exited by execution of a RETURN or
> END statement, it is not deallocated.
> Encountered 0 errors, 0 warnings, 1 information in file MY_MOD.F90.
>
> ------------------------------------------
>
> What is happening here? I understand that the function result must be
> around when it is assigned to 'a' in the main program. But after this
> assignment, what is happening to the allocated memory. Is it freed, or
> not? Is it something to worry about?
>
> Arno
>
I suppose the compiler is warning you of the consequences of overlapping
scope with CONTAINS. As the note says, automatic deallocation either
occurs at RETURN or not at all. Do you expect the compiler to figure
out where in the calling program it should deallocate? In a quick
search in MR&C, they point out that even with default automatic
deallocation, memory may not be recovered, so deallocate() is advisable.
I don't find explanation of the case you have set up, where you depend
on the compiler knowing that allocate on return will break your code.
| |
| Paul van Delst 2007-06-25, 10:07 pm |
| Arno wrote:
> If I pass the following program to the online Lahey Fortran Source
> Check, I receive a warning (actually an information item):
>
> program earth
>
> use my_mod
>
> implicit none
>
> integer,parameter :: n=3
> real(kind=8) :: a(n)
> integer :: i
>
> do i=1,n
> a(i) = i*1.d0
> enddo
>
> write(*,*) a
>
> a = modify(a)
>
> write(*,*) a
>
> end program earth
>
> --------------------------------------------------------
>
> module my_mod
>
> contains
>
> function modify(arr) result(res)
>
> implicit none
>
> real(kind=8),intent(in) :: arr(:)
> real(kind=8),dimension(:),allocatable :: res
>
> allocate(res(size(arr)))
> res = arr*2.d0
>
> end function modify
>
> end module my_mod
>
> -----------------------------------------
>
> The warning I get is:
>
> Compiling program unit my_mod at line 1:
> Module subprogram name(modify)
> 2064-I: "MY_MOD.F90", line 11: If local allocatable array 'res' is
> currently allocated when procedure exited by execution of a RETURN or
> END statement, it is not deallocated.
> Encountered 0 errors, 0 warnings, 1 information in file MY_MOD.F90.
>
> ------------------------------------------
>
> What is happening here? I understand that the function result must be
> around when it is assigned to 'a' in the main program. But after this
> assignment, what is happening to the allocated memory. Is it freed, or
> not? Is it something to worry about?
Hmm. I've never seen allocatables used like that before (not that that means anything :o).
Why not do the more usual for array-valued function results:
function modify(arr) result(res)
implicit none
real(kind=8),intent(in) :: arr(:)
real(kind=8) :: res(size(arr))
res = arr*2.d0
end function modify
??
cheers,
paulv
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
| |
|
|
>
>
>
In this case the size of res is known right away; it is the same as
the size of arr. But suppose that the size is to be determined within
the function, then I think allocatables are the way to go.
[color=darkred]
> I posted too quick - after looking at the calling program, why not use a subroutine rather
> than a function?
In the case of an assignment, I find the '='sign self-explaining,
whereas a subroutine is not always clear what is going on:
a = manipulate(b)
vs.
call manipulate(a,b)
In the first case, it is clear that b is manipulated and then stored
in a. In the second case I am not sure what is stored in what.
The other reason why I would sometimes rather use functions is in the
case of nested function calls:
call calc_lots_of_stuff(x,manipulate(b),n)
vs.
call manipulate(dummy,b)
call calc_lots_of_stuff(x,dummy,n)
> p.s. try not to use literal kind numbers.
You are right.
Arno
| |
| Richard Maine 2007-06-25, 10:07 pm |
| Tim Prince <timothyprince@sbcglobal.net> wrote:
> Arno wrote:
[eliding much]
....[color=darkred]
[color=darkred]
> I suppose the compiler is warning you of the consequences of overlapping
> scope with CONTAINS.
I don't understand that comment. I don't see anything here that has
anything to do with CONTAINS or "overlaping scope" (whatever that is).
> As the note says, automatic deallocation either
> occurs at RETURN or not at all.
While the message seems to say something like that, it is flat wrong.
> Do you expect the compiler to figure
> out where in the calling program it should deallocate?
Yes, I do. Because I expect compilers to follow the standard. As I have
said here before, allocatables cannot leak memory (except of course,
through compiler bugs). An allocatale function result is one of the
slightly complicated cases, but the standard *DOES* cover it -
explicitly as a spoecial case.
F2003 section 6.3.3.1, Dealocation of allocatable variables. Page 116,
first para (right after Note 6.24).
"If an executable construct references a function whose result is
either allocatable or..., and the function reference is executed, an
allocatable result... returned by the function is deallocated after
execution of the innermost executable construct containing the
reference."
In this case, the innermost executable construct containing the
reference is the assignment statement with the reference. (In most
cases, the "innermost executable construct" will be a single statement).
So, in short, the result is kept around through the assignment statement
in the main program, because it is needed there. But it is deallocated
after the assignment statement. Of course, the compiler is free to
optimize things to get the same effect, but that's beside the point.
I think that the message in question is confusing at best, and more
likely just wrong. I'd probably report it to the vendior as a bug. Other
than that, I'd ignore it. There is nothing at all wrong with this code.
You'd have problems trying to do simillar things with pointers, but
allocatables solve that class of problems (assuming you have a compiler
that supports the allocatable TR so that you can have thing slike
allocatabel function results at all).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Rich Townsend 2007-06-25, 10:07 pm |
| Richard Maine wrote:
> Tim Prince <timothyprince@sbcglobal.net> wrote:
>
> [eliding much]
> ...
>
>
> I don't understand that comment. I don't see anything here that has
> anything to do with CONTAINS or "overlaping scope" (whatever that is).
>
>
> While the message seems to say something like that, it is flat wrong.
>
>
> Yes, I do. Because I expect compilers to follow the standard. As I have
> said here before, allocatables cannot leak memory (except of course,
> through compiler bugs).
This is true in F95, but was it true in F90?
An allocatale function result is one of the
> slightly complicated cases, but the standard *DOES* cover it -
> explicitly as a spoecial case.
Important caveat here: Lahey's implementation of TR 15581 is an unsupported
'feature' of their compiler, and any bug reports concerning this implementation
are viewed -- quaintly -- as 'feature requests'.
>
> F2003 section 6.3.3.1, Dealocation of allocatable variables. Page 116,
> first para (right after Note 6.24).
>
> "If an executable construct references a function whose result is
> either allocatable or..., and the function reference is executed, an
> allocatable result... returned by the function is deallocated after
> execution of the innermost executable construct containing the
> reference."
>
> In this case, the innermost executable construct containing the
> reference is the assignment statement with the reference. (In most
> cases, the "innermost executable construct" will be a single statement).
>
> So, in short, the result is kept around through the assignment statement
> in the main program, because it is needed there. But it is deallocated
> after the assignment statement. Of course, the compiler is free to
> optimize things to get the same effect, but that's beside the point.
>
> I think that the message in question is confusing at best, and more
> likely just wrong. I'd probably report it to the vendior as a bug. Other
> than that, I'd ignore it. There is nothing at all wrong with this code.
> You'd have problems trying to do simillar things with pointers, but
> allocatables solve that class of problems (assuming you have a compiler
> that supports the allocatable TR so that you can have thing slike
> allocatabel function results at all).
>
| |
| Richard Maine 2007-06-25, 10:07 pm |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
> Richard Maine wrote:
>
> This is true in F95, but was it true in F90?
No. F90 allocatables were abysmal. They actually did worse than leak
memory. The kinds of things that you might think of as potentially
leaking memory instead left the allocatable in an undefined state. You
could no longer validly do *ANYTHING* with such an allocatable. You
couldn't allocate it, because it wasn't deallocated. You couldn't
deallocate it becase it wasn't allocated. You couldn't even inquire
about its status.
F95 fixed all that and got rid of the undefined allocation status. What
f95 didn't fix was the severe limitations on where you could use
allocatables at all. TR 15581 addressed most of that, with f2003 filling
in some "corners" (such as allocatable scalars).
But since the code in question has an allocatable function result, f90
seems pretty irrelevant. It requires at least f95+TR.
> Important caveat here: Lahey's implementation of TR 15581 is an
> unsupported 'feature' of their compiler, and any bug reports concerning
> this implementation are viewed -- quaintly -- as 'feature requests'.
Ok. Well, I can't address the question of how the vendor responds to bug
reports. That doesn't change whether or not it is a bug. In this case,
at least, the workaround is simple: just ignore the bogus message.
However, the message does make me suspect that there is a more serious
underlying bug. Perhaps the compiler does leak memory in this case;
that's what the message seems to say. As I mentioned before, compiler
bugs can, of course, leak memory.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Beliavsky 2007-06-25, 10:07 pm |
| On Jun 25, 11:25 am, Arno <arnoinp...@hotmail.com> wrote:
>
>
>
>
> In this case the size of res is known right away; it is the same as
> the size of arr. But suppose that the size is to be determined within
> the function, then I think allocatables are the way to go.
Yes, in Fortran 2003, which supports "allocation upon assignment", but
not in Fortran 95, where one should use a subroutine (rather than a
function) with an allocatable argument.
|
|
|
|
|