From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 2CAE9385843F; Wed, 9 Feb 2022 02:35:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2CAE9385843F Received: by mail-pf1-x429.google.com with SMTP id i186so1874570pfe.0; Tue, 08 Feb 2022 18:35:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=uPnm8lRzmRnxH4IhiSyX2Cp1km+Kz72AzfdtHOeJCvo=; b=BwLlc2+tPXWCi/qOi+WkNm5440rKKxvpNJMj4iSnjHi7+EaPj3gLxaGD6792mgTQEp 2stRpLAt+Y2kElKNhao5MQTd2oZoKfznVE6bCDXiHfIg5ptRWHgxRpPoX/20I+cqNmus DdoAK3eo2p2gs4cCnDTXrG3y93+BUikt5/vch/7uWcaBOThypyyYAsd7SWuVXKxVKkvD ZQsWocbNSofjQPrH5xcdqVokkwH7IQt93/BiMLcBz4QUcLcAzUSVqTyYhQp+LSOXq1wi Xd67E3q0Whc0a/Kac8umTakOWHL41QgRcF4x22Cig+bziowpDrF5af8HUCfwd0Eh8KY1 sc/Q== X-Gm-Message-State: AOAM533f4e0PuLig2yQYPR3OarJQVR5K1Cu2GaeVQW2P8qlVhhRz7FJd MbX0Gu0DnXnb+GKrvpwxajI= X-Google-Smtp-Source: ABdhPJxd2avpGr2T2zRvDn6cqhgobrXkk2BASDQZHyBYbA2zKSPFkv0R4G/qHSjyHPkNv3qz5xThlA== X-Received: by 2002:a63:f30e:: with SMTP id l14mr222714pgh.410.1644374125897; Tue, 08 Feb 2022 18:35:25 -0800 (PST) Received: from [192.168.1.28] ([50.46.203.130]) by smtp.gmail.com with ESMTPSA id x23sm17316905pfh.216.2022.02.08.18.35.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Feb 2022 18:35:25 -0800 (PST) Message-ID: Date: Tue, 8 Feb 2022 19:35:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization Content-Language: en-US To: Harald Anlauf , Paul Richard Thomas Cc: gcc-patches , Alessandro Fanfarillo , Andrew Benson , "fortran@gcc.gnu.org" References: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> From: Jerry D In-Reply-To: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 02:35:28 -0000 Remember the days when reading very old cryptic Fortran code? Remember the fixed line lengths and cryptic variable names! I fear the Standards committee has achieved history with the Standard itself it is so difficult to understand sometimes. Cheers to Paul and Harald for digging on this. Jerry On 2/8/22 11:29 AM, Harald Anlauf via Fortran wrote: > 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