public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
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: Tue, 8 Feb 2022 19:29:56 +0100	[thread overview]
Message-ID: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> (raw)
Message-ID: <20220208182956.gn1-sWxKMmOVCapMpNSqUnKP-p3UQGcAAMvdA2pYL30@z> (raw)
In-Reply-To: <CAGkQGiLFv7a_m-ZL7L1Mj3uskhG-AaiMW3T7XWNQxsN=5Psv-Q@mail.gmail.com>

Hi Paul,

Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran:
> Hi Harald,
> 
> Thanks for giving the patch a whirl.
> 
> 
>> the parent components as an array. I strongly suspect that, from reading
>>> 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However,
>> this
>>> is another issue to come back to in the future.
>>
>> Could you specify which version of Intel you tried?
>>
> 
> ifort (IFORT) 2021.1 Beta 20201112

ok, that's good to know.

>>
>> Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with:
>>
>> 131
>>
>> This test also fails with crayftn 11 & 12 and nagfor 7.0,
>> but in a different place.
>>

I have run your modified version of finalize_38.f90, and now I see
that you can get a bloody head just from scratching too much...

crayftn 12.0.2:

  1,  3,  1
  2,  21,  0
  11,  3,  2
  12,  21,  1
  21,  4,  3
  23,  21,  22 | 42,  43
  31,  6,  4
  41,  7,  5
  51,  9,  7
  61,  10,  8
  71,  13,  10
  101,  2,  1
  102,  4,  3
  111,  3,  2
  121,  4,  2
  122,  0,  4
  123,  5,  6 | 2*0
  131,  5,  2
  132,  0,  4
  133,  7,  8 | 2*0
  141,  6,  3
  151,  10,  5
  161,  16,  9
  171,  18,  11
  175,  0.,  20. | 10.,  20.

nagfor 7.0:

  1 0 1
  11 1 2
  23 21 22 | 42 43
  71 9 10
  72 11 99
  131 3 2
  132 5 4
  141 4 3
  151 6 5
  161 10 9
  171 12 11

Intel 2021.5.0:

          131           3           2
          132           0           4
          133           5           6 |           0           0
          141           4           3
          151           7           5
          152           3           0
          153           0           0 |           1           3
forrtl: severe (174): SIGSEGV, segmentation fault occurred
[...]


That got me reading 7.5.6.3, where is says in paragraph 1:

"When an intrinsic assignment statement is executed (10.2.1.3), if the
variable is not an unallocated allocatable variable, it is finalized
after evaluation of expr and before the definition of the variable.
..."

Looking at the beginning of the testcase code (abridged):

   type(simple), allocatable :: MyType, MyType2
   type(simple) :: ThyType = simple(21), ThyType2 = simple(22)

! The original PR - one finalization of 'var' before (re)allocation.
   MyType = ThyType
   call test(1, 0, [0,0], 0)


This is an intrinsic assignment.

Naively I would expect MyType to be initially unallocated.

ThyType is not allocatable and non-pointer and cannot become
undefined here and would not play any role in finalization.

I am probably too blind-sighted to see why there should be
a finalization here.  What am I missing?

> Could you use the attached version of finalize_38.f90 with crayftn and NAG?
> All the stop statements are replaced with prints. Ifort gives:
>           131           3           2
>           132           0           4
>           133           5           6 |           0           0
>           141           4           3
>           151           7           5
>           152           3           0
>           153           0           0 |           1           3
>           161          13           9
>           162          20           0
>           163           0           0 |          10          20
>           171          14          11

I think it is a good idea to have these prints in the testcase
whenever there is a departure from expectations.  So print&stop?

Furthermore, for the sake of health of people reading the testcases
later, I think it would not harm to add more explanations why we
expect a certain behavior... ;-)

> Best regards
> 
> Paul

Best regards,
Harald


  reply	other threads:[~2022-02-08 18:30 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 [this message]
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
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=9a2667e2-8055-bcac-1862-05c8ac60ce7a@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).