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

[FortranFan]

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:

[fortran]

   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

[/fortran]

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,

[Andrew_Smith]

Having a FINAL statement is optional and it should be impossible that any error would occur with standard conforming code having no FINAL statements. Judging by your pseudo code I would think this is a compiler bug.

[Steven_L_Intel1]

Please provide a real example and we'll be glad to investigate.