MOVE_ALLOC problems with 12.1.1

MOVE_ALLOC problems with 12.1.1

The following:

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

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

U:projectsifort 12.1 testmove-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:projectsifort 12.1 testmove-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

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.

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

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

Regards,

Arjen

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.

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.

Steve - Intel Developer Support

Escalated as DPD200175822.

Steve - Intel Developer Support

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?

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

Steve - Intel Developer Support

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.

Steve - Intel Developer Support

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

Leave a Comment

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