Memory leak bug or user error when casting polymorphs inside overloaded operator function

[Williams__Ben]

Hello, problem in attached files. I've tried intel16.0 -> 19.0 and GCC 6.4 -> 7.2. All have the same issue which stinks of user error but I just can't see what I'm doing wrong. Opt level doesn't seem to matter. The example given is a vastly simplified version of what I was trying to do elsewhere with a high loop count to highlight the possible memory leak. - The calling routine is in ray_mod.f90 which allocates a few variables to either coord or coord3D. Here fixed to coord - Then a simple overloaded coord*real operation is performed- this results in mult_coord_real1 being called, in laser_mod.f90 - Inside mult_coord_real1 the function result is polymorphic and has to be allocated (cast to either coord or coord3D)- my suspicion is that the function result temporary is not being cleaned up and each time is pointed to a new bit of the heap. If leave this to run it eventually eats into the swap space and freezes the computer. I know I can use a subroutine to do this (and it works) but it isn't as neat. a = b*c is better than call subr(a,b,c) If I change the CLASS(coord), POINTER to be CLASS(coord),ALLOCATABLE then intel18 seems to work just fine but gcc still has an issue. But I was under the impression that pointers could be cast/allocated in such a way and any temporary would be cleaned up when out of scope- or am I wrong? If this is illegal, should the compiler throw an error? I've actually altered my data structures in the larger code to avoid this issue and remove all the SELECT CASE statements littered throughout but I'm still curious why this implementation didn't work Thanks, Ben Compile statement, debug mode: mpiifort -O0 -g -assume protect_parens -std03 -warn -fpe0 -nothreads -traceback -fltconsistency -C -heap-arrays 64 -fpic -fopenmp laser_mod.f90 ray_mod.f90

[Juergen_R_R]

sleep is an extension, but not standard Fortran. With nagfor (commenting out the sleep call) the program terminated normally, also for intel. I didn't use all the different flags you were using.

[Williams__Ben]

The issue is a memory leak, not whether the program will terminate correctly. It will eventually swap, machine dependent of course.

Yes l am aware l'm using an extension to the standard.  The reason for the sleep call is so I can inspect the memory usage before the program exits and this was simple enough. 

In the actual code the operator will be called billions of times before exit, filling all the RAM.

The question is really: why does the compiler allow me to allocate/cast the pointer function result when it's possible it may not be cleaned up upon handing back to the calling routine? Declaring allocatable instead of pointer is fine (under Intel18) and as both should be on the heap I'm surprised there's a difference. 

[Juergen_R_R]

This doesn't surprise me, if you generate a new pointer in every do loop iteration. Why don't you use allocatables, then you can by definition not produce a memory leak.

[Williams__Ben]

That's one way of looking at it I suppose. I still don't understand why the memory the function result pertains to isn't freed. If I was just creating a new pointer every iteration in the main code without deallocating then yes I'd chew through the memory, which I am technically doing.  But as a function result I thought it'd be automatically deallocated upon return. 

Why do you say "by definition you cannot produce a memory leak" for allocatables?

I've found a comment on another question that might answer my query: 

However, POINTER arrays that are allocated are not automatically released when you exit their scope

If that's the case then I should never be allowed to point to a function result in the first place, it will always leak.