The following:
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.
[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.
链接已复制
8 回复数
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.
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.
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?
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.
