Re: Overloading OPERATOR(+): my usage causing memory leaks.

On Nov 3, 3:10 pm, Paul van Delst <paul.vande...@xxxxxxxx> wrote:
Richard Maine wrote:
Paul van Delst <paul.vande...@xxxxxxxx> wrote:

Richard Maine wrote:

P.S. As far as I can see, your defined assignment does the same thing as
the intrinsic assignment would...
Wha..? You mean, sans my defined assignment routine, doing
  a = b
where a and b are derived types with allocatable components, the compiler
should allocate the components of the lhs before doing the assignments?


Remember I'm still using f95+tr15581 compilers. I am rearranging things
for an easy switch to using type bound procedures once f2003 compilers
become routinely available. Does f95+tr15581 do more behind-the-scenes
housekeeping than I thought?

Yes. From N1379 (as close as I have handy to the final version of the

    For intrinsic assignment of objects of a derived type containing an
    allocatable array component, the allocatable array component of the
    variable on the left-hand-side receives the allocation status and,
    if allocated, the bounds and value of the corresponding component of
    the expression.

It then goes on to cover some fine points about possible optimizations
of and the effects of the allocatable component also being a target.

I did not know that. Let's see what happens in my test program when I remove my defined
assignment function so that intrinsic assignment is used instead.....


Holy crap.... the memory leaks have disappeared! Let me test the actual code I'm working

OMG! No memory leaks there either! All 8000 tests passed, 88.9MB deallocated!

So it would appear removal of my assignment function did, in fact, allow the compiler to
optimise the process in the add operation when intrinsic assignment is used. This is
brilliant. Not only have the memory leaks gone, but I've eliminated the need for an
assignment procedure.

Thanks so very much.


Some of these memory leaks with gfortran are well-known. Paul Thomas
had developed a -fcheck=memleak (or some such named option) to help
track down leaks in not only user code but also gfortran. Sadly, that
was lightly tested and withered in the mailing list. There are plans
revamp the internal representation in array descriptors. It is hoped
some (if not all) of these leaks will be caught at that time.



Relevant Pages

  • Re: Pointer use/ mem.leak gfortran
    ... Please post this to the gfortran list and submit a report to gcc ... memory leaks from failure to free temporary copies. ...   REAL:: tt ...   ALLOCATE(buffer(y,z,dmn,6)) ...
  • Re: TARGET attribute for dummy arguments: when is it needed?
    ... Start with problems relating to undefined pointer status. ... Memory leaks all over the place. ... sure not to allocate it, ... assignment does the "obvious" thing. ...
  • Re: gfortran problem
    ... conform or weren't allocated before the assignment. ... otherwise no automatic reallocation is ... Syntax error in character length specification at ... Syntax error in ALLOCATE statement at ...
  • Re: Non-Blocking versus blocking
    ...   always @ ... must execute the two blocks sequentially at the ... But when we use nonblocking assignment, ...
  • Re: Serialization of derived data types
    ... That's part of the definition of intrinsic assignment. ... components are done by pointer assignment. ... association one does not allocate memory. ...