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 2D2123858D20; Mon, 20 Feb 2023 11:07:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D2123858D20 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,312,1669104000"; d="scan'208";a="97571511" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 20 Feb 2023 03:07:52 -0800 IronPort-SDR: x52Xw39DHvQf0nrqyJvwrjbSLo7ylBvZOwTGUxYMTEyblUTI3f0TeFhyBbSWuxiUWgyoMhVUQP DtmgobaW7wAVfWDLTAGlhgTdCgmzpA4AWvit+WOdQnvwEc4ZeHo6nPPCDNaJzTETQjIybHSmQ5 T+PUuDdKKvn33+y8dlQMJxrTrPQ760fJ0f65YiZOvL3gKP1AyM92IasJuwr7bShUaHkZxAX+29 GttVid2I2Ad6bj8tjdv7gy7dS1YA2LDiEr5rX4vOPBMSnJecAmtO5mI/w80iYDqxiq2JVY1Q8a Ve4= Message-ID: <34e0f9e6-ebb8-ce86-ea11-08b37e5be1f8@codesourcery.com> Date: Mon, 20 Feb 2023 12:07:43 +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 Content-Language: en-US To: Richard Biener CC: , gcc-patches , fortran , Paul Richard Thomas References: <27cd606a-f019-60b2-a9c8-0a570433b5eb@codesourcery.com> 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-12.mgc.mentorg.com (139.181.222.12) 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 20.02.23 11:41, Richard Biener wrote: > Generally SAVE_EXPR is used to make sure an expression is only evaluated > once. It's DECL_EXPR that ensures something is evaluated early > and available. So generally "unwrapping" a SAVE_EXPR looks dangerous > to me unless the SAVE_EXPR is really never necessary. For VLA-kind of variables, SAVE_EXPR makes sense (code wise: if '!deferred') - and that use in gfortran should remain unchanged. However, Fortran also has deferred-length variables where one has: character(len=3D:), pointer :: str ! ... allocate(character(len=3D42) :: str) !... end which has the dump: integer(kind=3D8) .str; character(kind=3D1)[1:.str] * str; str =3D (character(kind=3D1)[1:.str] *) __builtin_malloc (42); .str =3D 42; The length variable is - a bit oddly - linked to the data variable its TREE_TYPE - i.e. via the upper bound for the domain / TYPE_SIZE / TYPE_SIZE_UNIT. Currently, it happens that the SAVE_EXPR is used, e.g. size =3D D.1234; // which D.1234 is the SAVE_EXPR instead of the current value size =3D .str; which leads to wrong results. As '.str' is an aritificial variable, the issue of a user modifying the value does not exist. * * * As mentioned in the TODO for 'deferred', I think we really want to have NULL as upper value for the domain for the type, but that requires literally hundred of changes to the compiler, which I do not want to due during Stage 4, but that are eventually required.* =E2=80=94 In any case, this patch fixes some of the issues in the meanwhile. Tobias * The number of deferred-length bugs is really huge; especially when used with derived types. ----------------- 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