Length type parameter example takes a while to compile

[IanH]

The attached appears to take an indefinite period of time to compile with 15.0.1.148.  Before it started playing up like this (not sure what I changed) I strongly suspect it demonstrated a runtime issue with length type parameters. 

(Alternatively it demonstrated this user's incompetence associated with length type parameters.)

>ifort "2014-11-24 read-a-block.f90"
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.1.148 Build 20141023
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

ifort: error #10273: Fatal error in C:\PROGRA~2\Intel\COMPOS~2\bin\intel64\fortcom, terminated by 0xffffffd6

(The fatal error results when I press Ctrl-Break after a minutes or so.  With my attention span that is several metric indefinite periods.).

[Martyn_C_Intel]

It looks like more like the compiler is hung.

Version 15 was the first one to support parametrized derived types, so there's no point comparing to earlier compilers.

If you compile just the type and finalization routine (see below) with -stand f08, you see a warning

len_type3.f90(15): warning #7026: Non-standard extension.   [REALDATABLOCK&:]
    TYPE(RealDataBlock(*)), INTENT(IN) :: the_block

That suggests to me the compiler doesn't expect parametrized derived types to be finalized, but we'll see what the experts say. In any case, the compiler shouldn't just hang.

MODULE DataBlocks
  IMPLICIT NONE

  TYPE, PUBLIC :: RealDataBlock(block_size)
    INTEGER, LEN :: block_size
    TYPE(RealDataBlock(:)), POINTER :: next => NULL()
    REAL, PRIVATE :: data(block_size)
  CONTAINS
    FINAL :: final_block
  END TYPE RealDataBlock
 
CONTAINS

  SUBROUTINE final_block(the_block)
    TYPE(RealDataBlock(*)), INTENT(INOUT) :: the_block
    IF (ASSOCIATED(the_block%next)) DEALLOCATE(the_block%next)
  END SUBROUTINE final_block
 
END MODULE DataBlocks

[Martyn_C_Intel]

No reasons yet why the compiler should not support this. (I did read that dummy arguments of finalization subroutines should not have intent(out), but changing this made no difference).

The issue has been escalated to the compiler developers. We'll let you know what happens. Thanks for reporting.

[Martyn_C_Intel]

It is confirmed that this should work. The compiler was looping; this is being fixed, and the fix should be available in the next update. I'll post when that is available.

[Martyn_C_Intel]

Unfortunately, another problem was found after the immediate issue was fixed. This is still being worked.

[Martyn_C_Intel]

A fix for the second problem is being implemented. We'll post again when a compiler containing it becomes available.

[Martyn_C_Intel]

This second problem is also fixed in the 17.0 compiler and the most recent 16.0 compilers, available for download from the Intel Registration Center.