Arrays of unlimited polymorphic variables

[Simon_Geard]

I am trying to use arrays of unlimited polymorphic variables. These work if I use 1-d arrays but I get an access violation if I try 2-d arrays. Should this work?

C:\>ifort upv.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.0.103 Build 20130728
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

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

-out:upv.exe
-subsystem:console
upv.obj

C:\>upv
 a is integer
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
upv.exe            000000013FA312B6  Unknown               Unknown  Unknown
upv.exe            000000013FA820E6  Unknown               Unknown  Unknown
upv.exe            000000013FA6C1BB  Unknown               Unknown  Unknown
kernel32.dll       000000007771652D  Unknown               Unknown  Unknown
ntdll.dll          000000007794C521  Unknown               Unknown  Unknown

I get the same result with version 12.1.0.233.

[Lorri_M_Intel]

Short answer: No, I don't think this should work.  Although, alas, we don't give an error.

I'm still trying to find where in the standard it states this, but I believe that the polymorphic dummy argument must be either ALLOCATABLE, POINTER or assumed-shape.  In other words, not adjustable.

If we declare your dummy argument as rank-1, assumed-shape, then an error happens when you try to pass a 2-dimensional array to it.

      Does this help?

                       --Lorri

[Steven_L_Intel1]

I believe that the code is legal. As Lorri notes, if the dummy argument is made assumed-shape, then there is a rank mismatch and the compiler gives an error. [F2008, p294, lines 32-34] But otherwise the standard allows changing ranks with the following exception:

"If the procedure is nonelemental and is referenced by a generic name or as a defined operator or defined assignment, the ranks of the actual arguments and corresponding dummy arguments shall agree." [F2008, p294, lines 29-31]

There is no requirement that a polymorphic dummy argument be allocatable, pointer or assumed-shape. It could be a simple scalar. The first call works just fine, but in the second, what I think is happening is that the compiler fails to notice that the corresponding dummy is rank 1 and goes ahead and creates a rank 2 array descriptor for it. This then creates problems when the code in the called routine tries to get at the type information, as it's not where it expects.

I'll file a report with the developers on this. Issue ID is DPD200247793.

[Simon_Geard]

Thanks for the info. I've decided to do it the old fashiond way and have separate procedures with a common interface for the calling code. The code has to be written so whether it is inside a select type or in a separate procedure doesn't really matter. What would be really nice would be a templating mechanism so I could avoid writing identical blocks of code for each data type.

The code I'm working on is essentially a wrapper for READ and WRITE with the data always being an array but types and ranks can differ. To use the interface warning mechanism I need to have a specific interface for every type/rank but the corresponding READ/WRITE is the same.