Quantcast
Channel: Intel® Software - Intel® Visual Fortran Compiler for Windows*
Viewing all articles
Browse latest Browse all 5691

Missing FINAL statement in a derived type: Strange run-time behavior during DEALLOCATE statement execution on the type

$
0
0

Say a derived type is declared with ALLOCATABLE attribute.  If the FINAL statement is missing in the derived type declaration, what should be the expected behavior if DEALLOCATE statement is executed on an object instance of this type?

I'd a situation where I forgot to add the FINAL statement to a derived type with type-bound procedures.  Using Intel Fortran compiler 14, SP1 (XE 14.0.1.139), if the program executable built with the Release Configuration was run, it just crashed with the "ProgramXYZ has stopped working" message.  If the program built with the Debug Configuration was run, an error message pop-up from Microsoft C++ Run-time Library was received with the message, "Debug Error!  Program XYZ...exe Damage before 0x... which was allocated by aligned routine  (Press Retry to debug the appplication".  Is this only to be expected?

To illustrate my situatio further, here is some pseudo-code:

   MODULE MyMod
       TYPE, PUBLIC :: MyType
           TYPE(SomeType) :: SomeData
       CONTAINS
           PROCEDURE, PASS(This) :: SomeProc

	           !.. FINAL :: CleanMyType  !. <-- Final statement was missing
       END TYPE MyType
   CONTAINS
         !.. Code for SomeProc

	         ...

	         !.. Code for "finalizer" CleanMyType

	         ...

	   END MODULE MyMod
   PROGRAM Test

	      ...

	      TYPE(MyType), ALLOCATABLE :: MyTypeInstance

	      ...

	      ALLOCATE(MyTypeInstance, STAT=ErrorCode)

	      ...

	      !.. The statement below generates run-time error if FINAL statement is missing

	      DEALLOCATE(MyTypeInstance, STAT=ErrorCode)

	      ...

	   END PROGRAM Test

It will be nice if some option, say /check:finalizer, can be made available along the lines of /check:uninit, /check:bounds, etc. that would generate a more user-friendly run-time response.  It took me a couple of hours to figure out my problem.

Interestingly NO run-time error is generated if all the code is included in the project for the program executable.  In my case, the derived type is packaged in a separate Windows DLL that gets loaded by the program executable.  The above mentioned run-time errors only occur in this scenario; is this another defect?

Owing to policy restrictions, I am unable to post the complete example on this forum.  However if the Intel staff is interested in following up on this, I can send the files privately.

Thanks in advance for all feedback and comments,

 


Viewing all articles
Browse latest Browse all 5691

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>