polymorphic component + assignment + MOVE_ALLOC = 'uh oh'

[IanH]

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.))

[IanH]

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]

What do you expect: tmp(:SIZE(a)) = a to do in the second program?

[IanH]

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]

Thanks. Escalated as issue DPD200236021.

[IanH]

More thoughts/examples, investigated with /warn:all /check:all /standard-semantics.

[IanH]

Perhaps a workaround presents, but see comments in this for more problematic areas. Structure constructor handling is a bit sick.

[Steven_L_Intel1]

Thanks, Ian.

[IanH]

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

[Steven_L_Intel1]

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

[Steven_L_Intel1]

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

[Steven_L_Intel1]

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