Possible bug with finalization implementation

Possible bug with finalization implementation

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

AttachmentSize
Download test-20120731.f902.81 KB
Regards, David PyF95++
5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

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

Regards, David PyF95++

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)

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)

Leave a Comment

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