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.
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.
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.
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.