topic Ian, it might be related. We in Intel® Fortran Compiler

for_dealloc_all_nocheck

IanH — Mon, 09 Sep 2013 20:28:49 GMT

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.

The partially-transcribed

Lorri_M_Intel — Tue, 10 Sep 2013 10:16:07 GMT

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

I'm getting an access

IanH — Tue, 10 Sep 2013 12:01:46 GMT

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

IanH — Thu, 12 Sep 2013 11:24:45 GMT

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.

Thank you for the simple

Lorri_M_Intel — Thu, 12 Sep 2013 12:31:13 GMT

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

This bug is fixed for the

Steven_L_Intel1 — Thu, 24 Apr 2014 15:47:21 GMT

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

The random monkeys that get

IanH — Thu, 24 Apr 2014 23:35:03 GMT

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

Steven_L_Intel1 — Fri, 25 Apr 2014 14:59:33 GMT

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

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

Ian, the developers say that

Steven_L_Intel1 — Fri, 25 Apr 2014 19:56:59 GMT

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