Elemental procedures and allocatable arguments

[IanH]

Many moons ago I wrote some code.  In compliance with my personal coding standards, that code contained gross errors. 

Today I tried poking my code into a different compiler, which told me in no uncertain terms that my code was badly bodgy - it violated some constraint thingy.  How rude.  That said it would appear ifort has been letting me get away with things it shouldn't.

[fortran]ELEMENTAL FUNCTION ElementalProcsCannotHaveAllocatableArgs(C1289_in_F2008)  &
    RESULT(AndElementalFunctionResultsCannotBeAllocatableEither)
  IMPLICIT NONE
  INTEGER, INTENT(IN), ALLOCATABLE :: C1289_in_F2008
  CHARACTER(14), ALLOCATABLE :: AndElementalFunctionResultsCannotBeAllocatableEither
  ALLOCATE(AndElementalFunctionResultsCannotBeAllocatableEither)
  AndElementalFunctionResultsCannotBeAllocatableEither = 'C1290 in F2008'
END FUNCTION ElementalProcsCannotHaveAllocatableArgs
[/fortran]

[plain]>ifort /c /check:all /warn:all /standard-semantics /stand elementalsub.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.

elementalsub.f90(1): remark #7712: This variable has not been used.   [C1289_IN_F2008]
ELEMENTAL FUNCTION ElementalProcsCannotHaveAllocatableArgs(C1289_in_F2008)  &
-----------------------------------------------------------^[/plain]

[andrew_4619]

is /stand the same as /stand none? /stand f08 perhaps? Just a guess I can't test at the moment.

[IanH]

For current compilers, /stand without a keyword is the same as /stand:f03. That's just there to formally rule out some bizarre extension (one that would be contrary to the compiler's own documentation) and to give the compiler a nudge towards diagnosing constraint violations.

The extension would be a bit bizarre, because there's a philosophical issue - it is difficult to actually give useful meaning to an elemental procedure with allocatable arguments (and I think the function result case too).  If a dummy argument is allocatable, then the actual argument has to be allocatable.  Arrays and scalars might be allocatable, but array elements never are.  So you have a procedure that is supposed to be able to operate on conformable arrays and scalars (because it is elemental), but it can't work on arrays, which means it can only work on scalars, so what was the point of making it elemental again?  Perhaps there's the possibility for some arguments must be scalar/other arguments can be either sort of use, but we're getting a bit obscure now.

I'm pretty sure I've been calling this procedure in code.  I'm a bit baffled as to how it could have worked!

[Steven_L_Intel1]

This is not a deliberate extension. I will ask the developers to make both of these conditions an error. Issue ID is DPD200247686. The corresponding constraints in F2003 are C1277 and C1278.

[Steven_L_Intel1]

This is fixed in 15.0 Update 2, available now from the Intel Registration Center.