Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29393 Discussions

Possible bug with finalization implementation

david_car
New Contributor I
1,039 Views

Hi,

Attached you'll find an example of ambiguous behavior with finalization.  For one, the finalization is called when one pointer to a derived type is assigned to another pointer to the same derived type.  When a derived type contains a pointer to another derived type and assignment occurs the finalization bound procedure for that type is not called.  I'm not sure which is the correct behavior.  Look at the scope() procedure and the comments within.  Thanks.

-Dave

0 Kudos
4 Replies
Neil_Carlson
Beginner
1,039 Views
Dave- Your statement foo2%b = foo%b involving type(bar) variables uses intrinsic assignment (the defined assignment was not made public) so by 4.5.6.3.9 the variable foo2%b should have been finalized, so the Intel compiler is wrong here. The second assignment pf2 = pf1 is similar to begin with. It also uses intrinsic assignment, so pf2 is finalized as a first step. This means calling the final procedure delete (which the Intel compiler manages to get right in this case somehow), followed by finalizing each of the finalizable components of pf2. The pointer component b isn't finalizable, though, because it is a pointer (1.3.74), so the type(bar) final routine isn't called here. -Neil
0 Kudos
david_car
New Contributor I
1,039 Views
Neil- Yes. I agree with your assessment. I purposefully left the defined assignment private so that the intrinsic assignment would be used. I think there is a problem with the intel compiler unless the interpretation for the pointer within the derived type is not finalizable simply because it is contained within a derived type, regardless if a direct assignment is being made. Thanks for looking at the problem and your insight. -Dave
0 Kudos
Kevin_D_Intel
Employee
1,039 Views

Thank you for reproducer Dave and to both for your analysis. I reported this to the Fortran Developers (internal tracking id noted below) for thier analysis and will update the thread when I know more.

(Internal tracking id: DPD200237444)

(Resolution Update on 01/23/2014): This defect is fixed in the Intel® Fortran Composer XE 2013 SP1 Initial Release (2013.1.0.080- Linux)

0 Kudos
Kevin_D_Intel
Employee
1,038 Views

I apologize for the overdue notification. This defect was fixed in the Intel® Fortran Composer XE 2013 SP1 Initial Release (2013.1.0.080 - Linux)

0 Kudos
Reply