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

附件尺寸
下载 test-20120731.f902.81 KB
Regards, David PyF95++
5 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

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)

发表评论

登录添加评论。还不是成员?立即加入