Possible bug with finalization implementation

Possible bug with finalization implementation

Аватар пользователя david.car
david.car
сб, 13/10/2012 - 10:34

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 КБ
Regards, David PyF95++
RSS Вверх
4 posts / 0 новое
Последнее сообщение
Пожалуйста, обратитесь к странице Уведомление об оптимизации для более подробной информации относительно производительности и оптимизации в программных продуктах компании Intel.
Аватар пользователя Neil Carlson
Neil Carlson
сб, 13/10/2012 - 14:20

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

Вверх
Аватар пользователя david.car
david.car
сб, 13/10/2012 - 16:38

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++
Вверх
Аватар пользователя Kevin Davis (Intel)
Kevin Davis (Intel)
пн, 15/10/2012 - 02:17

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)

Вверх

Зарегистрируйтесь, чтобы оставить комментарий.