GNU Fortran: deallocate(p, stat= ? )

[Ev. Drikos]

This is a cross-posting from stackoverflow.com
https://stackoverflow.com/questions/65973285/after-a-call-to-setjmp-can-pthread-t-be-different

which is a personal attempt for a nice to have feature in gfortran, ie:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504

Of course gfortran isn't supposed to support such a feature but editing
the compiler is an advantage of open source. Yet, I faced an unexpected
situation with OpenMP threads. I'm wondering if I must add somewhere an
OpenMP mechanism (ie omp critical) or there is no problem in this case.

So, this is work in progress that may be abandoned. Any ideas?


Ev. Drikos

[JCampbell]

As a Fortran user, I am puzzled why "deallocate (p2, stat=ios) ; write (*,*) 'status = ',ios" is allowed to abort.
Steve Kargl appears to complain that your code is "invalid Fortran", but the question should be asked ;
"What is the point of "stat=ios" if not to report if there is a problem when deallocating a variable"?
That a variable is no longer allocated is hardly "invalid Fortran", but the presence of stat= suggests some uncertainty about it's allocatable status and a way of testing and deallocating if already allocated.

For the case of read (..., iostat=ios), tf there is a problem, the program does not crash but reports an error via ios.
Why can't deallocate provide the same functionality ?

Your question about OpenMP threads needs more information, especially if the variable is private or shared, where more care would be required and critical.

[Ev. Drikos]

On 20/02/2021 07:30, JCampbell wrote:
> ...

> As a Fortran user, I am puzzled why "deallocate (p2, stat=ios) ; write (*,*) 'status = ',ios" is allowed to abort.

It's the underlying system call 'free' that behaves this way. BTW when I
build a particular package with gcc-4.8.5 I also face a, Linux specific,
invalid free (as caught by malloc_check_=1) not handled by this hack. So
there are known limitations.

> Steve Kargl appears to complain that your code is "invalid Fortran", but the question should be asked ;

His last comment was that a compiler can do anything, including what
the user expected.

So, such a bug fix may offer also covered protection from compiler bugs,
ie for PRs 93691 & 98433. It needs a little fine tuning for PR/97123 if
one doesn't compile with the option '-std=legacy'.

> "What is the point of "stat=ios" if not to report if there is a problem when deallocating a variable"?
> That a variable is no longer allocated is hardly "invalid Fortran", but the presence of stat= suggests some uncertainty about it's allocatable status and a way of testing and deallocating if already allocated.
>
> For the case of read (..., iostat=ios), tf there is a problem, the program does not crash but reports an error via ios.
> Why can't deallocate provide the same functionality ?
>
> Your question about OpenMP threads needs more information, especially if the variable is private or shared, where more care would be required and critical.
>

I had tried to code a function without local variables at all. I'm not
sure it's a bug if a thread reports a different address throughout it's
life-cycle, but I'm not confident that would be ok. So I restricted it.


Thank you

[Themos Tsikas]

On Saturday, 20 February 2021 at 05:30:46 UTC, JCampbell wrote:
> As a Fortran user, I am puzzled why "deallocate (p2, stat=ios) ; write (*,*) 'status = ',ios" is allowed to abort.

Because p2 is undefined.

> Steve Kargl appears to complain that your code is "invalid Fortran", but the question should be asked ;

It *is* invalid Fortran.

> "What is the point of "stat=ios" if not to report if there is a problem when deallocating a variable"?

The point is that if it were otherwise, every user of Pointer (including those users who obeyed the Standard) would have to pay a heavier price for it because of the runtime overhead required.

If you are unsure of your pointers' status, nullify them and use a Fortran processor with a garbage collecting runtime to recycle the memory leaks.

> That a variable is no longer allocated is hardly "invalid Fortran", but the presence of stat= suggests some uncertainty about it's allocatable status and a way of testing and deallocating if already allocated.

Pointers have three states (undefined, disassociated, associated) but that information usually lives in the mind of the programmer, not a bit in the runtime. DEALLOCATE prohibits being given a pointer in the first state. The "uncertainty" is about the other two states, and that is carried by a bit in the runtime (as it is cheap to do so). You are asking for a runtime that carries complete information. Some compilers offer an option to detect undefined pointers (and pay the corresponding performance penalty) but the one that I know of terminates the program with an informative message and would not allow DEALLOCATE to return with a particular STAT.

> For the case of read (..., iostat=ios), tf there is a problem, the program does not crash but reports an error via ios.

The program can crash in a READ nevertheless. Try giving it a UNIT or FMT through an undefined or disassociated Pointer.

> Why can't deallocate provide the same functionality ?

As you see, it does!

Themos Tsikas, NAG Ltd

[Ev. Drikos]

On 20/02/2021 13:12, Themos Tsikas wrote:
> Because p2 is undefined.

The short story is that free doesn't return a value, it's void.