MOVE_ALLOC problems with 12.1.1

[IanH]

The following:

[fortran]PROGRAM IFort12_1_being_a_PITA
  IMPLICIT NONE  

  TYPE :: Parent
    INTEGER :: dummy
  END TYPE Parent
  
  TYPE :: Token
    INTEGER :: type
  END TYPE Token   
  
  CALL one_deep
CONTAINS
  SUBROUTINE one_deep  
    !# Must be nested call.
    CALL two_deep                         
  END SUBROUTINE one_deep
      
  SUBROUTINE two_deep
    !# Require this unused allocatable.
    TYPE(Token), ALLOCATABLE :: tlist(:)  
    CLASS(Parent), ALLOCATABLE :: ex  
    !****
    CALL Parse(ex)
    PRINT "('Ok')"
  END SUBROUTINE two_deep     !# Program explodes here.

  SUBROUTINE Parse(ex)
    CLASS(Parent), INTENT(OUT), ALLOCATABLE :: ex
    !----
    !# Require this to not be polymorphic
    TYPE(Parent), ALLOCATABLE :: from
    !****
    ALLOCATE(from)
    CALL MOVE_ALLOC(from, ex)         
  END SUBROUTINE Parse
END PROGRAM IFort12_1_being_a_PITA
[/fortran]

dies (unfairly IMHO) at runtime at the line indicated when compiled with 12.1.1 (update 7) on ia32 with /Od.

[plain]U:\projects\ifort 12.1 test\move-alloc>ifort /check:all /warn:all /standard-sema
ntics /traceback /Od ParsingTests.f90
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 1
2.1.1.258 Build 20111011
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

ParsingTests.f90(22): remark #7712: This variable has not been used.   [TLIST]
    TYPE(Token), ALLOCATABLE :: tlist(:)
--------------------------------^
Microsoft  Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:ParsingTests.exe
-subsystem:console
-incremental:no
ParsingTests.obj

U:\projects\ifort 12.1 test\move-alloc>ParsingTests.exe
Ok
forrtl: severe (157): Program Exception - access violation
Image              PC        Routine            Line        Source
ParsingTests.exe   004058F5  Unknown               Unknown  Unknown
ParsingTests.exe   0040580C  Unknown               Unknown  Unknown
ParsingTests.exe   00401175  _IFORT12_1_BEING_          27  ParsingTests.f90
ParsingTests.exe   00401030  _IFORT12_1_BEING_          17  ParsingTests.f90
ParsingTests.exe   00401021  _MAIN__                    13  ParsingTests.f90
ParsingTests.exe   0044A5C3  Unknown               Unknown  Unknown
ParsingTests.exe   00430634  Unknown               Unknown  Unknown
kernel32.dll       7C817077  Unknown               Unknown  Unknown
[/plain]

This snippet extracted from a larger "test" program, which I'm pretty sure used to run successfully with pre 12.1 versions, but perhaps I was delusional, just lucky, or both.

[Arjen_Markus]

FWIW, I compiled, linked and run your program with gfortran 4.6.2 and that gave no problems.

Regards,

Arjen

[mecej4]

This may be of little value for explaining or pinpointing the error, but may be useful as a workaround:

Removing /Od and keeping your other options creates a program that runs with no errors.

Your example runs with the 12.0.5.221 compiler with no errors.

[Steven_L_Intel1]

I can reproduce the problem. The error occurs when the compiled code attempts to deallocate all local allocatable variables on exit from the routine - something has corrupted the memory manager's data or a descriptor for one of the variables. I can confirm that it does seem to work ok with Update 5 - my guess is that you really need /dbglibs to see the problem as this causes the C run-time library to add extra debugging support for memory allocations.

[Steven_L_Intel1]

Escalated as DPD200175822.

[IanH]

Things seem to work ok if the type that is moved is polymorphic (CLASS(Parent) ... on line 32 rather than TYPE(Parent)). Is that a real workaround, or is the memory corruption or whatever just moved elsewhere?

[Steven_L_Intel1]

My guess is that just moves the problem. It is highly dependent on memory layout.

[Steven_L_Intel1]

We have fixed this problem in the compiler sources - the fix will appear in a future version. The problem occurs when MOVE_ALLOC is used with the FROM being a non-polymorphic and the TO being polymorphic. If both FROM and TO are polymorphic, it's fine.

[IanH]

Thanks - the both being polymorphic thing will be a handy workaround in the meantime, or I would have lots of wasted code.