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 530C5382CC3A; Thu, 19 Aug 2021 07:52:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 530C5382CC3A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 0ZUgIBcVC41saVQ8z9FuS7fOgTKyVIUyrohwQa909zkgU2ucGLvvwYu62UlXfhXKRtJPzYnInC k4ayl9qoV1b8EbG1MxxYe6dPsXuq3fG3otGFHt5ZEsLgHqDMVzWP188/P6kWEB4R4KN1JrtWDx 0Vd9PFOqKVym9SVY0HPQDvD3RTq3bZ9Yv0VaXi5hZRF4thA4uKzcN/D8HXOzr+ca8nj8TJ7hHa 20mcJ+2Cx5k0xB8+BDxv9ZLHyZ6kS09/LbGHRuhPewAzjvuBy2RdbdUo8gJYQYHaIuH0Vo3x0q 2+wxjjWPyZPUZtG/rSa7LLfd X-IronPort-AV: E=Sophos;i="5.84,334,1620720000"; d="diff'?scan'208";a="65088960" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 18 Aug 2021 23:52:30 -0800 IronPort-SDR: g1wlaOunFx1r9CeosynFEmUo368K6/XiTHZR3QoNAvu2Up4slJ/nZ7D7uDnYW7Y/miEyG7aXCb RpU6g4GPJEMqnP1eCoSq5zLRkcEOiSSz0eZNmLtaP+wv1pOjKZxjn0Inb6lcj5l0tc/vSmfp9y iE4N8exqoMKAFuP0VsAb/ARcUnXAmY4sh/0wt+/sbvOEZO8cVIwq/jtxo8fdaRz8DMPHOYtL9H ArMGyr4OMwN8Htv2gt+7XT69sE144BITnx2HKTU7pKwYthwXlGZUVHy0RzwIXlFjkc8PWQFxzR Kqk= Subject: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514 To: Harald Anlauf , Tobias Burnus CC: Bernhard Reutner-Fischer , Harald Anlauf via Gcc-patches , fortran References: <20210610122435.296a207d@nbbrfq> From: Tobias Burnus Message-ID: <8d25c317-74fa-d8a2-724f-de6944fa602e@codesourcery.com> Date: Thu, 19 Aug 2021 09:52:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------985B4102A41CF8C459D5242B" Content-Language: en-US X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.7 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, KAM_SHORT, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP 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: Thu, 19 Aug 2021 07:52:43 -0000 --------------985B4102A41CF8C459D5242B Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Harald, On 18.08.21 23:01, Harald Anlauf wrote: >> Von: "Tobias Burnus" >>> Note, however, that gfc_simplify_len still won't handle neither >>> deferred strings nor their substrings. >> Obviously, nonsubstrings cannot be simplified but I do not >> see why len(str(1:2)) cannot or should not be simplified. > well, here's an example that Intel rejects: > ... > character(:), allocatable :: str > end type u > type(u) :: q > ... > integer, parameter :: k3 =3D len (q% str (3:4)) ! Rejected by Intel > > pr100950-ww.f90(7): error #6814: When using this inquiry function, the le= ngth of this object cannot be evaluated to a constant. [LEN] I think the question is really how to interpret "10.1.12 Constant expressio= n" "(4) a specification inquiry where each designator or argument is ... (b) a variable whose properties inquired about are not (i) assumed, (ii) deferred, or (iii) defined by an expression that is not a constant expression," And as the substring bounds are constant expressions, one can argue that (4)(b) is fulfilled as (i)=E2=80=93(iii) do not apply. I am inclined to say that the Intel compiler has a bug by not accepting it =E2=80=93 but as written before, I regard sub-string length (esp. with const expr) inquiries as an odd corner case which is unlikely to occur in real-world code. >> However, there is no reason why the user cannot do [...] > Maybe you can enlighten me here. [...] I can't as I did not understand your question. However ... >> But, IMHO, the latter remark does_not_ imply that we >> shall/must/have to accept code like: >> >> if (allocated(str)) then >> block >> integer, parameter :: n =3D len(str(:5)) >> end block >> endif > So shall we not simplify here (and thus reject it)? > This is important! Or silently simplify and accept it? I tried to draw the line between simplification =E2=80=93 to generate bette= r code =E2=80=93 and 'constant expression' handling (accept where permitted, diagnose non-standard-conforming code). =E2=80=94 However, nearly but not quite alwa= ys: if it can be simplified to a constant the standard also regards it as constant expression. I think in for the purpose of the examples in this email thread, we do not need to distinguish the two. =E2=80=94 And can always simplify deferred-length substrings where the substring bounds are const expressions (or the lower-bound is absent and, hence, 1). >> With the caveat from above that len() is rather special, >> there is no real reason why: str_array(:)(4:5) cannot be handled. >> (=E2=86=92 len =3D 2). > Good point. This is fixed in the revised patch and tested for. Still does not work =E2=80=93 or rather: ...%t(:)(3:4) [i.e. substring with= array section] and ...%str(3:4) [i.e. substring of deferred-length scalar] both do work but if one combines the two (=E2=86=92 ...%str2(:)(3:4), i.e. substring of = deferred-length array section), it does not: Array =E2=80=98r=E2=80=99 at (1) is a variable, which does not reduce to a = constant expression for: --- a/gcc/testsuite/gfortran.dg/pr100950.f90 +++ b/gcc/testsuite/gfortran.dg/pr100950.f90 @@ -15,2 +15,3 @@ program p character(len=3D:), allocatable :: str + character(len=3D:), allocatable :: str2(:) end type t_ @@ -24,2 +25,4 @@ program p integer, parameter :: l6 =3D len (r(1)%str (3:4)) + integer, parameter :: l7 =3D len (r(1)%str2(1)(3:4)) + integer, parameter :: l8 =3D len (r(1)%str2(:)(3:4)) which feels odd. >>> The updated patch regtests fine. OK? >> Looks good to me except for the caveats. > Regtested again. [...] > Well, there's already > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101735 I have added the example to the PR. >> For deferred length, I have no strong opinion; [...] > Actually, this is now an important point. If we really want > to allow to handle substrings of deferred length strings > in constant expressions, the new patch would be fine, I think handling len=3D: substrings is fine. In principle, LGTM =E2=80=93 except I wonder what we do about the len(r(1)%str(1)(3:4)); I think we really do handle most code available and I would like to close this topic =E2=80=93 but still it feels a bit odd to leave this bit out. I was also wondering whether we should check that the compile-time simplification works =E2=80=93 i.e. use -fdump-tree-original f= or this; I attached a patch for this. Thanks, 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 --------------985B4102A41CF8C459D5242B Content-Type: text/x-patch; charset="UTF-8"; name="patch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.diff" diff --git a/gcc/testsuite/gfortran.dg/pr100950.f90 b/gcc/testsuite/gfortran.dg/pr100950.f90 index 7de589fe882..b9dcef0a7af 100644 --- a/gcc/testsuite/gfortran.dg/pr100950.f90 +++ b/gcc/testsuite/gfortran.dg/pr100950.f90 @@ -1,0 +2 @@ +! { dg-additional-options "-fdump-tree-original" } @@ -15,0 +17 @@ program p + character(len=:), allocatable :: str2(:) @@ -24,0 +27,2 @@ program p +! integer, parameter :: l7 = len (r(1)%str2(1)(3:4)) +! integer, parameter :: l8 = len (r(1)%str2(:)(3:4)) @@ -37,0 +42 @@ program p +! if (l3 /= 2 .or. l6 /= 2 .or. l7 /= 2 .or. l8 /= 2) stop 12 @@ -39,0 +45,4 @@ end + +! { dg-final { scan-tree-dump-times "_gfortran_stop_numeric" 2 "original" } } +! { dg-final { scan-tree-dump "_gfortran_stop_numeric \\(3, 0\\);" "original" } } +! { dg-final { scan-tree-dump "_gfortran_stop_numeric \\(7, 0\\);" "original" } } --------------985B4102A41CF8C459D5242B--