From: Harald Anlauf <anlauf@gmx.de>
To: fortran@gcc.gnu.org
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
Date: Thu, 10 Feb 2022 20:49:59 +0100 [thread overview]
Message-ID: <3cbaf568-84ac-8498-558f-9560fe395d66@gmx.de> (raw)
Message-ID: <20220210194959.1Y6Isn1intpxthOmxDI4Rqhf1eNUXSL9bNZI_t4eZe0@z> (raw)
In-Reply-To: <CAGkQGiKD4g1bwicx5qu1R18rn2bafFfFMWDiU3m=k4-+UPibBA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
> Conclusions on ifort:
> (i) The agreement between gfortran, with the patch applied, and ifort is
> strongest of all the other brands;
> (ii) The disagreements are all down to the treatment of the parent
> component of arrays of extended types: gfortran finalizes the parent
> component as an array, whereas ifort does a scalarization. I have a patch
> ready to do likewise.
>
> Overall conclusions:
> (i) Sort out whether or not derived type constructors are considered to be
> functions;
> (ii) Come to a conclusion about scalarization of parent components of
> extended type arrays;
> (iii) Check and, if necessary, correct the ordering of finalization in
> intrinsic assignment of class arrays.
> (iv) Finalization is difficult to graft on to existing pre-F2003 compilers,
> as witnessed by the range of implementations.
>
> I would be really grateful for thoughts on (i) and (ii). My gut feeling, as
> remarked in the submission, is that we should aim to be as close as
> possible, if not identical to, ifort. Happily, that is already the case.
I am really sorry to be such a bother, but before we think we should
do the same as Intel, we need to understand what Intel does and whether
that is actually correct. Or not inconsistent with the standard.
And I would really like to understand even the most simple, stupid case.
I did reduce testcase finalize_38.f90 to an almost bare minimum,
see attached, and changed the main to
type(simple), parameter :: ThyType = simple(21)
type(simple) :: ThyType2 = simple(22)
type(simple), allocatable :: MyType, MyType2
print *, "At start of program: ", final_count
MyType = ThyType
print *, "After 1st allocation:", final_count
MyType2 = ThyType2
print *, "After 2nd allocation:", final_count
Note that "ThyType" is now a parameter.
I tested the above and found:
Intel:
At start of program: 0
After 1st allocation: 1
After 2nd allocation: 2
NAG 7.0:
At start of program: 0
After 1st allocation: 0
After 2nd allocation: 0
Crayftn 12.0.2:
At start of program: 2
After 1st allocation: 2
After 2nd allocation: 2
Nvidia 22.1:
At start of program: 0
After 1st allocation: 0
After 2nd allocation: 0
So my stupid questions are:
- is ThyType invoking a constructor? It is a parameter, after all.
Should using it in an assignment invoke a destructor? If so why?
And why does Intel then increment the final_count?
- is the initialization of ThyType2 invoking a constructor?
It might, if that is the implementation in the compiler, but
should there be a finalization?
Then ThyType2 is used in an intrinsic assignment, basically the
same as the other one before. Now what is the difference?
Are all compilers correct, but I do not see it?
Someone please help!
> Best regards
>
> Paul
>
Cheers,
Harald
[-- Attachment #2: finalize_38b.f90 --]
[-- Type: text/x-fortran, Size: 737 bytes --]
module testmode
implicit none
type :: simple
integer :: ind
contains
final :: destructor1
end type simple
integer :: final_count = 0
contains
subroutine destructor1(self)
type(simple), intent(inout) :: self
final_count = final_count + 1
end subroutine destructor1
end module testmode
program test_final
use testmode
implicit none
type(simple), parameter :: ThyType = simple(21)
type(simple) :: ThyType2 = simple(22)
type(simple), allocatable :: MyType, MyType2
print *, "At start of program: ", final_count
MyType = ThyType
print *, "After 1st allocation:", final_count
MyType2 = ThyType2
print *, "After 2nd allocation:", final_count
end program test_final
next prev parent reply other threads:[~2022-02-10 19:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-03 17:14 Paul Richard Thomas
2022-02-07 21:09 ` Harald Anlauf
2022-02-07 21:09 ` Harald Anlauf
2022-02-08 11:22 ` Paul Richard Thomas
2022-02-08 18:29 ` Harald Anlauf
2022-02-08 18:29 ` Harald Anlauf
2022-02-09 2:35 ` Jerry D
2022-02-10 12:25 ` Paul Richard Thomas
2022-02-10 19:49 ` Harald Anlauf [this message]
2022-02-10 19:49 ` Harald Anlauf
2022-02-11 2:15 ` Jerry D
2022-02-11 9:08 ` Paul Richard Thomas
2022-02-11 21:08 ` Harald Anlauf
2022-02-11 21:08 ` Harald Anlauf
2022-02-11 21:59 ` Paul Richard Thomas
2022-02-16 18:49 ` Paul Richard Thomas
2022-02-17 20:55 ` Harald Anlauf
2022-02-17 20:55 ` Harald Anlauf
2022-02-17 21:23 ` Thomas Koenig
2022-02-18 18:06 ` Paul Richard Thomas
2023-01-02 13:15 ` Paul Richard Thomas
[not found] ` <trinity-a4069639-4079-4f60-b928-1fec82384b1e-1672953005015@3c-app-gmx-bap48>
2023-01-05 21:14 ` Fw: " Harald Anlauf
2023-01-06 3:08 ` Jerry D
2023-01-06 8:33 ` Harald Anlauf
2023-01-07 10:57 ` Paul Richard Thomas
2023-01-07 15:28 ` Thomas Koenig
2023-01-07 18:35 ` Paul Richard Thomas
2023-01-08 12:03 ` Thomas Koenig
2023-01-08 13:42 ` Paul Richard Thomas
2023-01-09 20:42 ` Aw: " Harald Anlauf
2023-01-11 20:56 ` Harald Anlauf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3cbaf568-84ac-8498-558f-9560fe395d66@gmx.de \
--to=anlauf@gmx.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).