for_dealloc_all_nocheck

for_dealloc_all_nocheck

IanH's picture

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.

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Lorri Menard (Intel)'s picture

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's picture

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's picture

Flushed him out...

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

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

That first traceback line is within for_dealloc_all_nocheck.

Lorri Menard (Intel)'s picture

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

Login to leave a comment.