for_dealloc_all_nocheck

[IanH]

What does the library function in the subject title do for its day job?  I'm a bit suspicious that it, or one of its friends, is getting up to no good behind my back.

[Lorri_M_Intel]

The partially-transcribed description from the source code says that this is "used in places in which we're doing an implicit deallocate, and so normal error checking for the base object is not wanted.  For example, if we're implicitly deallocating an intent(out) dummy arg and the base object is already deallocated, we don't want to generate an error."

So, she asks hesitantly, what are you seeing?

                   --Lorri

[IanH]

I'm getting an access violation on procedure entry (one that has several INTENT(OUT) allocatable derived type arguments, where the actual arguments are themselves components of an extended type).  Stepping the disassembly indicates that it is happening within this library function.  Thanks for the description - that will help me narrow down what to look at/keep in my attempts to get a reasonable size reproducer.

[IanH]

Flushed him out...

[fortran]MODULE ArrayConstructors
  IMPLICIT NONE
  PRIVATE
  PUBLIC :: ParseArrayConstructor
 
  TYPE, PUBLIC, ABSTRACT :: Expression
  END TYPE Expression
 
  TYPE, PUBLIC :: TypeParamValue
    CLASS(Expression), ALLOCATABLE :: int_expr
  END TYPE TypeParamValue
 
  TYPE, PUBLIC :: TypeSpec
    TYPE(TypeParamValue), ALLOCATABLE :: params(:)
  END TYPE TypeSpec
CONTAINS
  RECURSIVE SUBROUTINE ParseArrayConstructor(type_spec)
    TYPE(TypeSpec), INTENT(OUT), ALLOCATABLE :: type_spec
  END SUBROUTINE ParseArrayConstructor
END MODULE ArrayConstructors

PROGRAM ParsingTests
  USE ArrayConstructors
  IMPLICIT NONE
  TYPE(TypeSpec), ALLOCATABLE :: ts
  !***************************************************************************
  CALL ParseArrayConstructor(ts)
END PROGRAM ParsingTests
[/fortran]

...is a pretty inocuous bit of code, but it explodes...

[plain]>ifort /debug /check:all /warn:all /standard-semantics /traceback /Od DesignatorTests.f90 && DesignatorTests.exe
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.

DesignatorTests.f90(17): remark #7712: This variable has not been used.   [TYPE_SPEC]
  RECURSIVE SUBROUTINE ParseArrayConstructor(type_spec)
---------------------------------------------^
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:DesignatorTests.exe
-debug
-pdb:DesignatorTests.pdb
-subsystem:console
-incremental:no
DesignatorTests.obj
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
DesignatorTests.e  000000013F3932E9  Unknown               Unknown  Unknown
DesignatorTests.e  000000013F3911CE  ARRAYCONSTRUCTORS          17  DesignatorTests.f90
DesignatorTests.e  000000013F391241  MAIN__                     27  DesignatorTests.f90
DesignatorTests.e  000000013F429896  Unknown               Unknown  Unknown
DesignatorTests.e  000000013F405FDF  Unknown               Unknown  Unknown
kernel32.dll       0000000076E1652D  Unknown               Unknown  Unknown
ntdll.dll          0000000076F4C541  Unknown               Unknown  Unknown[/plain]

That first traceback line is within for_dealloc_all_nocheck.

[Lorri_M_Intel]

Thank you for the simple reproducer!

I've escalated this as DPD200247990 and we'll let you know when we have a fix and/or simple workaround -

                  --Lorri

[Steven_L_Intel1]

This bug is fixed for the "2015" release later this year. The fix is not in the current beta.

[IanH]

The random monkeys that get involved in between writing source and running the program appear to have set things up such that the original code doesn't trigger the issue with the beta as released.  But for similar source and numerous other cases I'm now getting lots of "pointer points to something that can't be deallocated" runtime errors (premier support issue 6000048859).  Is this just the same bug with different spots?

(My recolelction when filing the bug report was that Premier support's listing of key beta features for 2015 still lists UDDTIO - I presume that should be parameterized derived types?)

[Steven_L_Intel1]

Ian, it might be related. We'll check it out.

Thanks also for the comment about the key beta features list.

[Steven_L_Intel1]

Ian, the developers say that your 6000048859 issue is the same one as this thread.