Other than a plain, old bug, can anyone think of situations where DEALLOCATE statement will not deallocate the provided object, but yet it won’t return an error code and an error message?
We’ve a major problem with one of the use cases for an important code library where DEALLOCATE statement runs into such a problem. The pseudo code is as follows:
... INTEGER :: Istat CHARACTER(LEN=80) :: ErrAlloc ... IF (ALLOCATED(Foo)) THEN DEALLOCATE(Foo, STAT=Istat, ERRMSG=ErrAlloc) ! <= returns Istat of 0 IF (Istat /= 0) THEN ... ! error handling RETURN END IF END IF ALLOCATE(Foo, STAT=Istat, ERRMSG=ErrAlloc) ! <-- failure, Istat=151; Foo already allocated. IF (Istat /= 0) THEN ... ! error handling RETURN END IF ...
where Foo is an instance of an extensible derived type containing allocatable components as well as type-bound procedures.
The issue is the ALLOCATE statement fails with an error code of 151 and returns an error message, “an allocatable array is already allocated.” because the DEALLOCATE in the code block just prior to this hasn't done its its job but hasn't returned an error. Note the IF (ALLOCATED(..)) check does indeed return true.
Isn't DEALLOCATE statement always supposed to return a non-zero error code if it is unable to deallocate the object for any reason?
The application structure is as follows: a Fortran main program calls DLL A which calls DLL B. The main program has a “TYPE(Foo_t), ALLOCATABLE :: Foo” kind of declaration. Foo is an argument specified with “TYPE (Foo_t), INTENT(INOUT) :: ” in some of the procedures in DLLs A and B which, under certain circumstances, will need to deallocate and reallocate Foo. The code is built with /standard-semantics compiler option.
Any thoughts on what to check before I start thinking of this as a bug?