Subroutine local and saved derived type with allocatable

[legu]

Hi,

in a subroutine, I have a local variable which is a derived type t_1
that contains an allocatable array f1, this local variable is SAVEd,
like this: type(t_1), save :: d
After a conditional test on allocated(d%f1), the variable's member is
allocated or not, in such a way it is allocated once, when the
subroutine is first called.

With ifort (10.1,linux), it works as expected, but gfortran (4.2.1,
4.2.3, X 10.5.3) doesn't keep d%f1 allocated and it is allocated each
time the subroutine is called.

Is it a bug of gfortran ?
How can I check for memory leaking ?

Thx,
Legu.

[Richard Maine]

legu <bool...@gmail.com> wrote:

> in a subroutine, I have a local variable which is a derived type t_1
> that contains an allocatable array f1, this local variable is SAVEd,
> like this: type(t_1), save :: d
> After a conditional test on allocated(d%f1), the variable's member is
> allocated or not, in such a way it is allocated once, when the
> subroutine is first called.

Standard response number 1 to questions asking for help with code: show
the code instead of describing it. This is *VERY* common, not specific
to you. I just use "you" below because it is easier to write that way,
rather than to say anything personal.

If you need help with the code, that pretty much implies that you don't
have a thorough understanding of all the possible factors that could be
relevant. Thus, your description could easily fail to mention what turn
out to be the most important parts. People can spend an awful lot of
time trying to debug something based on a description that turns out not
to have the data critically needed to answer the questions.

In your particular case, the description actually sounds pretty coherent
and does mention those things that occur to me as the most obvious. So
perhaps you have described it adequately. The description does make it
sound like a compiler bug. Nonetheless, I, at least, am not willing to
draw conclusions about it illustrating a compiler bug based solely on
such a description, without seeing code, preferably a complete, testable
example. Shouldn't be hard to do an example of that unless there are
subtle interactions with other things such that the problem goes away in
small examples.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

[legu]

You're right Richard, I'm working on a minimalist working example (the
code is pretty big).

Meanwhile, is there a sound reason (fortran standard ?) which could
explain the allocatable member of a subroutine local and saved derived
type is always reported as not allocated ?

Legu

[legu]

Program main

type derived_type
real, allocatable :: array(:)
end type derived_type

call test()
call test()

contains

subroutine test()
type(derived_type), save :: local

if ( allocated(local%array) ) then
print*,'already allocated'
else
allocate( local%array(1) )
print*,'allocated'
end if

end subroutine test
end program main

With gfortran 4.2.1, 4.2.3 on os X 10.5.3, this gives:
allocated
allocated

whereas, with ifort 10.1 on linux, it gives the expected:
allocated
already allocated

[James Van Buskirk]

"legu" <bool...@gmail.com> wrote in message
news:53952ff2-5878-4ca4...@h1g2000prh.googlegroups.com...

> With gfortran 4.2.1, 4.2.3 on os X 10.5.3, this gives:
> allocated
> allocated

C:\gfortran\clf\component_test>type component_test1.f90
Program main

type derived_type
real, allocatable :: array(:)
end type derived_type

call test()
call test()

contains

subroutine test()
type(derived_type), save :: local

if ( allocated(local%array) ) then
print*,'already allocated'
else
allocate( local%array(1) )
print*,'allocated'
end if

end subroutine test
end program main

C:\gfortran\clf\component_test>gfortran
component_test1.f90 -ocomponent_test1

C:\gfortran\clf\component_test>component_test1
allocated
already allocated

C:\gfortran\clf\component_test>gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc/configure -q --prefix=/var/tmp/w64 --with-sysroot=/var/t
mp/w64 --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --silent
Thread model: win32
gcc version 4.4.0 20080528 (experimental) (GCC)

gfortran has been getting better lately. Many errors I see posted
here are fixed in more recent versions.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[Richard Maine]

legu <bool...@gmail.com> wrote:

[excellent code sample]

> With gfortran 4.2.1, 4.2.3 on os X 10.5.3, this gives:
> allocated
> allocated
>
> whereas, with ifort 10.1 on linux, it gives the expected:
> allocated
> already allocated

I'd say that was pretty clear and definitive. Sounds like a gfortran
bug. Though as James said, perhaps it might have been fixed in a later
version.

[Daniel Franke]

legu wrote:
> With ifort (10.1,linux), it works as expected, but gfortran (4.2.1,
> 4.2.3, X 10.5.3) doesn't keep d%f1 allocated and it is allocated each
> time the subroutine is called.
>
> Is it a bug of gfortran ?

In those versions, allocatable components have some rough edges left. This
is being worked on. However, from your description it is very likely that
it's a compiler bug. If it turns out to be (from the minimal example you
are working on), could you please also file a PR at gcc.gnu.org/bugzilla?

> How can I check for memory leaking ?

Try valgrind (www.valgrind.org).

Thanks

Daniel

[Tobias Burnus]

On 6 Jun., 11:15, Daniel Franke <nos...@nowhere.com> wrote:
> > With ifort (10.1,linux), it works as expected, but gfortran (4.2.1,
> > 4.2.3, X 10.5.3) doesn't keep d%f1 allocated and it is allocated each
> > time the subroutine is called.

> However, from your description it is very likely that
> it's a compiler bug.

It is a compiler bug, but it is fixed in 4.3.x (and 4.4.0). As it is
no regression, it is extremely unlikely that the fix will be
backported to 4.2.x, especially as there is the general notion that
4.3 is a good version.

4.4.0 binaries (nightly developer builds)* are available from:
http://gcc.gnu.org/wiki/GFortranBinaries#MacOS

Tobias

* Highlights of 4.4 currently are OpenMP 3 support and some more
Fortran 200x features (http://gcc.gnu.org/wiki/GFortran#news) plus a
couple bugfixes [153 bugreport/feature request numbers for this year's
commits].

[legu]

I found this bug report submitted earlier this year as I was looking
for reporting it. With gfortran 4.4 it works fine, thanks.

Legu.