From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 60B9B3858D37 for ; Sun, 9 Jun 2024 20:35:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 60B9B3858D37 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 60B9B3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=116.202.254.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717965336; cv=none; b=Xty+gXGjuhgGON+HLK4djbqss+F6+NoOb4y5gAzgi2ms+5di4zuQEes3varyRyvLSYnqQ3eNQL0UOiOgJRkQcia7qmf0deXe9onhX13vXV/ePCA+YeXjBmQb03adpVYQZcyIy4BIu8dxL2kDFzES4gv3IhnGtqHcK4w4oZ0xFzo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717965336; c=relaxed/simple; bh=ypL/S2RLf4Ocy3HalPWZgxU6GEUAkgXdON4UeLanfD4=; h=To:From:Subject:Date:Message-ID:Mime-Version; b=ph25Pr+aXIxXbX5ioHdwTS+Fi4/wSLv+g1SRlcYYzsyeb+UjgpIiL3pLezwPO0fUZ+R4LqBKjpgfZ//UvyXd2LNjiTwHyTjJQqvftW1abTI6KUWgLynDby4SnY9aTmsd28VI9iY1LmtPGz9HczSh0oUgtF+HlvPJvORc6Ha6ZqE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1sGPGG-00075t-OS for gcc-patches@gcc.gnu.org; Sun, 09 Jun 2024 22:35:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [Patch, fortran] PR59104 Date: Sun, 9 Jun 2024 22:35:25 +0200 Message-ID: <74b99484-7cd9-4e76-a40f-2b9c844ae99f@gmx.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20240609203525.vvmTiuZ0r3yUsuuMkdH0OggN-nXFhbkPkSd6ht_aVA0@z> Hi Paul, your approach sounds entirely reasonable. But as the following addition to the testcase shows, there seem to be loopholes left. When I add the following to function f: integer :: l1(size(y)) integer :: l2(size(z)) print *, size (l1), size (l2), size (z) I get: 0 0 3 Expected: 2 3 3 Can you please check? Thanks, Harald Am 09.06.24 um 17:57 schrieb Paul Richard Thomas: > Hi All, > > I have extended the testcase - see below and have > s/dependent_decls_2/dependent_decls_2.f90/ in the ChnageLog. > > Cheers > > Paul > > ! { dg-do run } > ! > ! Fix for PR59104 in which the dependence on the old style function result > ! was not taken into account in the ordering of auto array allocation and > ! characters with dependent lengths. > ! > ! Contributed by Tobias Burnus > ! > module m > implicit none > integer, parameter :: dp = kind([double precision::]) > contains > function f(x) > integer, intent(in) :: x > real(dp) f(x/2) > real(dp) g(x/2) > integer y(size (f)+1) ! This was the original problem > integer z(size (f) + size (y)) ! Found in development of the fix > integer w(size (f) + size (y) + x) ! Check dummy is OK > f = 10.0 > y = 1 ! Stop -Wall from complaining > z = 1 > g = 1 > w = 1 > if (size (f) .ne. 1) stop 1 > if (size (g) .ne. 1) stop 2 > if (size (y) .ne. 2) stop 3 > if (size (z) .ne. 3) stop 4 > if (size (w) .ne. 5) stop 5 > end function f > function e(x) result(f) > integer, intent(in) :: x > real(dp) f(x/2) > real(dp) g(x/2) > integer y(size (f)+1) > integer z(size (f) + size (y)) ! As was this. > integer w(size (f) + size (y) + x) > f = 10.0 > y = 1 > z = 1 > g = 1 > w = 1 > if (size (f) .ne. 2) stop 6 > if (size (g) .ne. 2) stop 7 > if (size (y) .ne. 3) stop 8 > if (size (z) .ne. 5) stop 9 > if (size (w) .ne. 9) stop 10 > end function > function d(x) ! After fixes to arrays, what was needed was known! > integer, intent(in) :: x > character(len = x/2) :: d > character(len = len (d)) :: line > character(len = len (d) + len (line)) :: line2 > character(len = len (d) + len (line) + x) :: line3 > line = repeat ("a", len (d)) > line2 = repeat ("b", x) > line3 = repeat ("c", len (line3)) > if (len (line2) .ne. x) stop 11 > if (line3 .ne. "cccccccc") stop 12 > d = line > end > end module m > > program p > use m > implicit none > real(dp) y > > y = sum (f (2)) > if (int (y) .ne. 10) stop 13 > y = sum (e (4)) > if (int (y) .ne. 20) stop 14 > if (d (4) .ne. "aa") stop 15 > end program p > > > > On Sun, 9 Jun 2024 at 07:14, Paul Richard Thomas < > paul.richard.thomas@gmail.com> wrote: > >> Hi All, >> >> The attached fixes a problem that, judging by the comments, has been >> looked at periodically over the last ten years but just looked to be too >> fiendishly complicated to fix. This is not in small part because of the >> confusing ordering of dummies in the tlink chain and the unintuitive >> placement of all deferred initializations to the front of the init chain in >> the wrapped block. >> >> The result of the existing ordering is that the initialization code for >> non-dummy variables that depends on the function result occurs before any >> initialization code for the function result itself. The fix ensures that: >> (i) These variables are placed correctly in the tlink chain, respecting >> inter-dependencies; and (ii) The dependent initializations are placed at >> the end of the wrapped block init chain. The details appear in the >> comments in the patch. It is entirely possible that a less clunky fix >> exists but I failed to find it. >> >> OK for mainline? >> >> Regards >> >> Paul >> >> >> >> >