Elemental finalization

Elemental finalization

Following on from a recent c.l.f discussion I think there's a glitch with elemental finalization in the recent release that wasn't in previous releases.  The following little program seems to take an excessive period of time to run.

MODULE m20130902
  IMPLICIT NONE
  TYPE :: t
    INTEGER :: comp = 1
  CONTAINS
    FINAL :: t_final
  END TYPE t
CONTAINS
  ELEMENTAL SUBROUTINE t_final(arg)
    TYPE(t), INTENT(IN) :: arg
    IF (arg%comp /= 1) THEN
      CONTINUE
    END IF
  END SUBROUTINE t_final
END MODULE m20130902
PROGRAM finally
  USE m20130902
  IMPLICIT NONE
  TYPE(t) :: lhs(1)
  TYPE(t) :: rhs(0)
  lhs(:SIZE(rhs)) = rhs
END PROGRAM finally

>ifort /Od /check:all /warn:all /standard-semantics "2013-09-02 finally.f90"
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.0.103 Build 20130728
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.
"-out:2013-09-02 finally.exe"
-subsystem:console
"2013-09-02 finally.obj"
>"2013-09-02 finally.exe"
forrtl: error (200): program aborting due to control-C event
Image              PC                Routine            Line        Source
kernel32.dll       0000000076C94803  Unknown               Unknown  Unknown
kernel32.dll       0000000076C5652D  Unknown               Unknown  Unknown
ntdll.dll          0000000076D8C541  Unknown               Unknown  Unknown

(Ctrl-C pressed after a minute or so)

If you use the debugger on this similar program, and investigate values of the component of the argument to the finalizer, you see some odd stuff going on - component value of zero, lots of extra finalizer calls associated with the assignment.

!! Check that 
MODULE m20130902b
  IMPLICIT NONE
  TYPE :: t
    INTEGER :: component
  CONTAINS
    FINAL :: t_final
  END TYPE t
CONTAINS
  ELEMENTAL SUBROUTINE t_final(arg)
    TYPE(t), INTENT(IN) :: arg
    CONTINUE      ! Put a breakpoint here.
  END SUBROUTINE t_final
END MODULE m20130902b
PROGRAM finally_off_by_one
  USE m20130902b
  IMPLICIT NONE
  CALL sub
CONTAINS
  SUBROUTINE sub
    TYPE(t) :: array(3), scalar
    array%component = [1, 2, 3]
    scalar%component = 9
    array(2) = scalar
    ! Put another bp here to separate assignment related finalization 
    ! from end of scope related.
    PRINT *, array%component
  END SUBROUTINE sub
END PROGRAM finally_off_by_one

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Yeah, I had tried one of the earlier variants of that program and noticed the delay, though the program did eventually finish after about 15 seconds. I will try your version here and see what's going on.

Retired 12/31/2016

Thanks, Ian. I think something is walking off the end of a list here. I can reproduce problems with both test cases. Escalated as issue DPD200247880.

Retired 12/31/2016

I expect that this will be fixed in Update 1, planned for October.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today