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.

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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?


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.

Flushed him out...

MODULE ArrayConstructors
  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
  RECURSIVE SUBROUTINE ParseArrayConstructor(type_spec)
    TYPE(TypeSpec), INTENT(OUT), ALLOCATABLE :: type_spec
  END SUBROUTINE ParseArrayConstructor
END MODULE ArrayConstructors
PROGRAM ParsingTests
  USE ArrayConstructors
  TYPE(TypeSpec), ALLOCATABLE :: ts
  CALL ParseArrayConstructor(ts)
END PROGRAM ParsingTests a pretty inocuous bit of code, but it explodes...

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

That first traceback line is within for_dealloc_all_nocheck.

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 -


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

Retired 12/31/2016

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

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

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

Retired 12/31/2016

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

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today