From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 36492389366A; Mon, 20 Feb 2023 10:00:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36492389366A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.97,311,1669104000"; d="scan'208";a="97546437" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 19 Feb 2023 22:56:20 -0800 IronPort-SDR: 7jPyTxkABNLl94WTwGESeF17986nuOTwAULIpz8UDOtPYNOCk9uCMiFZhbB7Muf4jcw5P1nMev S1P4C+1igCgI3XFhmV5KE0+XnFRvPW6fodUjYLF69ZMegon3uBq01kS14wIvR1+SdP3nB20rqu MMAb4dw6xKy0X31kSeZsZdWm4eH3eekHgnnZn+P+fyDq0SVtKGgaHGMPhcsb64gGSwFoEI3Gmp CLe9+ToyZ00Muys0m3Bg8LMsIiQg3PscPLJQVM1QXCH3VbVKlVlZIBu679ss/kdI0r9PoRIFcI pEU= Message-ID: Date: Mon, 20 Feb 2023 07:56:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types To: CC: gcc-patches , fortran , Paul Richard Thomas References: <27cd606a-f019-60b2-a9c8-0a570433b5eb@codesourcery.com> Content-Language: en-US From: Tobias Burnus In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP 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: On 17.02.23 17:27, Steve Kargl wrote: > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote: >> OK for mainline? > Short version: no. Would you mind to write a reasoning beyond only a single word? >> subroutine foo(n) >> integer :: n >> integer :: array(n*5) >> integer :: my_len >> ... >> my_len =3D 5 >> block >> character(len=3Dmy_len, kind=3D4) :: str >> >> my_len =3D 99 >> print *, len(str) ! still shows 5 - not 99 >> end block >> end > Are you sure about the above comment? Yes - for three reasons: * On the what-feels-right side: It does not make any sense to print any other value than 5 given that 'str' has been declared with len =3D 5= . * On the GCC side, the SAVE_EXPR ensures that the length is evaluated early and then "saved" to ensure its original value is available * The quoted text from the standard implies that this is what should happen. Why do you think that printing "5" is wrong? GCC does so since years; it still does so with my patch. Hence, can you elaborate? And also state which value you did expect instead= ? * * * The patch itself is about *deferred* length parameters, i.e. 'len=3D:', and thus for code like: character(len=3D:), pointer :: str ... allocate(character(len=3D4) :: str) print *, len(str) ! should print 4 ... allocate(character(len=3D99) :: str) print *, len(str) ! should now print 99 ... Currently, the SAVE_EXPR causes that the original value might get used, which is often 0 (by chance 0 initialized) or some random value like 57385973, depending what on what was on the stack before. - There are more issues with deferred strings, but at least one is solved by not having a SAVE_EXPR for deferred-length character strings. Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955