Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

polymorphic component + assignment + MOVE_ALLOC = 'uh oh'

IanH
榮譽貢獻者 III
2,113 檢視

The following snippet, when compiled using ifort 13.0.0, gives surprising results.

[fortran]
MODULE abc
  IMPLICIT NONE
 
  TYPE :: InnerPoly
  END TYPE InnerPoly
 
  TYPE :: Container
    CLASS(InnerPoly), ALLOCATABLE :: item
  END TYPE Container
 
  TYPE :: Base
    TYPE(Container), ALLOCATABLE :: cont(:)
  END TYPE Base
END MODULE abc

PROGRAM OhNoNowICantGrow
  USE abc
  IMPLICIT NONE
  CLASS(Base), ALLOCATABLE :: a
  TYPE(Container), ALLOCATABLE :: tmp(:)
  !****
  ALLOCATE(a)
 
  ALLOCATE(a%cont(1))
 
  ! allocate bigger, assign, swap idiom for array expansion.
  ALLOCATE(tmp(SIZE(a%cont)+1))
  PRINT "('size of tmp:',I0)", SIZE(tmp)
  tmp(:SIZE(a%cont)) = a%cont
  CALL MOVE_ALLOC(tmp, a%cont)
 
  PRINT "('size of a%cont:',I0)", SIZE(a%cont)  
END PROGRAM OhNoNowICantGrow
[/fortran]

[plain]

>ifort /check:all /warn:all /standard-semantics "OhNoNowICantGrow.f90" && "OhNoNowICantGrow.exe"

Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 13.0.0.089 Build 20120731
Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:OhNoNowICantGrow.exe
-subsystem:console
OhNoNowICantGrow.obj
size of tmp:2
size of a%cont:1

[/plain]

Bigger examples throw access violations.

Advice on possible work arounds much appreciated - that pattern for expanding an array is in very common use in my code.

(Tips on how to post code examples in forum text also appreciated!  (Later edit to give the syntax highlighting instructions a whirl.))

0 積分
11 回應
IanH
榮譽貢獻者 III
2,113 檢視
Simplifying some more, and then this starts to look rather familiar... ~~~~ MODULE abc IMPLICIT NONE TYPE :: InnerPoly END TYPE InnerPoly TYPE :: Container CLASS(InnerPoly), ALLOCATABLE :: item END TYPE Container END MODULE abc PROGRAM OhNoNowICantGrow USE abc IMPLICIT NONE TYPE(Container), ALLOCATABLE :: a(:) TYPE(Container), ALLOCATABLE :: tmp(:) !**** ALLOCATE(a(1)) PRINT "('size of tmp:',I0)", SIZE(tmp) tmp(:SIZE(a)) = a PRINT "('size of tmp:',I0)", SIZE(tmp) CALL MOVE_ALLOC(tmp, a) PRINT "('size of a:',I0)", SIZE(a) END PROGRAM OhNoNowICantGrow ~~~~ a bit like... http://software.intel.com/en-us/forums/topic/287152 :( (Has mecej4 changed his forum id?)
Steven_L_Intel1
2,113 檢視
What do you expect: tmp(:SIZE(a)) = a to do in the second program?
IanH
榮譽貢獻者 III
2,113 檢視
Well, for what I posted - absolutely nothing useful! Oops. Apologies - copy and paste error transferring stuff to the forum - I was changing the example as I wrote the post. Immediately before the first PRINT in the second program insert an ALLOCATE(tmp(SIZE(a)+1)). The complete example is: ~~~~ MODULE abc IMPLICIT NONE TYPE :: InnerPoly END TYPE InnerPoly TYPE :: Container CLASS(InnerPoly), ALLOCATABLE :: item END TYPE Container END MODULE abc PROGRAM OhNoNowICantGrow USE abc IMPLICIT NONE TYPE(Container), ALLOCATABLE :: a(:) TYPE(Container), ALLOCATABLE :: tmp(:) !**** ALLOCATE(a(1)) ! allocate bigger, assign, swap idiom for array expansion. ALLOCATE(tmp(SIZE(a)+1)) PRINT "('size of tmp:',I0)", SIZE(tmp) tmp(:SIZE(a)) = a PRINT "('size of tmp:',I0)", SIZE(tmp) CALL MOVE_ALLOC(tmp, a) PRINT "('size of a:',I0)", SIZE(a) END PROGRAM OhNoNowICantGrow ~~~~ >ifort /check:all /warn:all /standard-semantics OhNoNowICantGrow.f90 Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 13.0.0.089 Build 20120731 Copyright (C) 1985-2012 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. -out:OhNoNowICantGrow.exe -subsystem:console OhNoNowICantGrow.obj >OhNoNowICantGrow.exe size of tmp:2 size of tmp:1 size of a:1 ~~~~ I don't expect the assignment to an array section of tmp to change the size of tmp.
Steven_L_Intel1
2,113 檢視
Thanks. Escalated as issue DPD200236021.
IanH
榮譽貢獻者 III
2,113 檢視
More thoughts/examples, investigated with /warn:all /check:all /standard-semantics.
IanH
榮譽貢獻者 III
2,113 檢視
Perhaps a workaround presents, but see comments in this for more problematic areas. Structure constructor handling is a bit sick.
Steven_L_Intel1
2,113 檢視
Thanks, Ian.
IanH
榮譽貢獻者 III
2,113 檢視

So.... 14 isn't going to be my lucky number with respect to polymorphic components?

Steven_L_Intel1
2,113 檢視

It might be. I will check on your specific issue on Monday.

Steven_L_Intel1
2,113 檢視

Your program revealed more than one problem with the compiler. One has been fixed, another is still being worked on.

Steven_L_Intel1
2,113 檢視

The second problem has now been fixed. The fix should appear in an October update.

回覆