From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 8AC7F385DC15; Fri, 20 Aug 2021 14:19:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8AC7F385DC15 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: zG5Exgf1cyZVpuRp+k1e4he90kG1JrxhlpE0wvIgMiWBpjUyPIjR+L184K/JFq/Ly0dwo9Ntqe gqxIz5cwOrI3HJPMFgkblAevXcquooHlUfa3cgLDog1r1oy4oYfZy2g054kTlre9hDUdQU2/0n IaXelzB+hzqdp5HFxpkpzNdEEZ2JzR1ADiEh6k8NAc+9I1z9c1Af9PtLpxgrPbAj0PDVoK9+II ABPnKp9UD3C6nKU3+Oeu1DbKgAYXhXnHvrHLqCSY4u1U5uvJ5557T6+NZMNb9FlhDssjf7PtRH MlVFwxjx+Gqaou6sZDr2B1uJ X-IronPort-AV: E=Sophos;i="5.84,337,1620720000"; d="scan'208";a="67434130" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 20 Aug 2021 06:19:28 -0800 IronPort-SDR: 2K8S9vACUd6smBu7y1X8sYmnEBPdxF8R9ngRaKUh9hSAIZF5IRjjbMyg9ZYe9WgTcG2mMNfifm FqHAS/bpWj9xKi0UbxF/fXw7IQdxBq7unolKsFIfKCbl4saFRJ0qjDPB9j7r0tC7/hWOcC+kL4 8i3RqX7eq5LDH5HLU3Tag98yImB1IDuYIaXA0iPoUwBNzklEbhnBtPYBYv6lJ81x5eISLwebU7 QVVnTfYpi9bR+XU8iqF8cuVY1v9hKFKjKOtW869IidLiMUmeX++PBsfcO6Mf30uFM57Rkf5Vmc z0w= Subject: Re: Aw: Re: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514 To: Harald Anlauf CC: , "H.J. Lu" , , fortran References: <8d25c317-74fa-d8a2-724f-de6944fa602e@codesourcery.com> <20210820091618.GB2380545@tucnak> <20210820101251.GF2380545@tucnak> From: Tobias Burnus Message-ID: <08347883-b9a9-0291-14e8-f6e232eb9de0@codesourcery.com> Date: Fri, 20 Aug 2021 16:19:20 +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: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, 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: Fri, 20 Aug 2021 14:19:31 -0000 Hi Harald, On 20.08.21 14:17, Harald Anlauf wrote: >> I can confirm this. =E2=80=93 I think in order to reduce the clutter, th= e >> diagnostic probably should be removed. > I am unable to prove that we will never that check. So how about: > diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c > index eaabbffca4d..04722a8640c 100644 > --- a/gcc/fortran/simplify.c > +++ b/gcc/fortran/simplify.c > @@ -4552,27 +4552,13 @@ substring_has_constant_len (gfc_expr *e) > > if (istart <=3D iend) > { > - char buffer[21]; > - if (istart < 1) > - { > - sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, istart); > - gfc_error ("Substring start index (%s) at %L below 1", > - buffer, &ref->u.ss.start->where); > - return false; > - } > - > /* For deferred strings use end index as proxy for length. */ > if (e->ts.deferred) > length =3D iend; > else > length =3D gfc_mpz_get_hwi (ref->u.ss.length->length->value.inte= ger); > - if (iend > length) > - { > - sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, iend); > - gfc_error ("Substring end index (%s) at %L exceeds string lengt= h", > - buffer, &ref->u.ss.end->where); > - return false; > - } > + > + gcc_assert (istart >=3D 1 && iend <=3D length); > length =3D iend - istart + 1; > } > else > > Or skip the gcc_assert and cross fingers... (we then would not even need = to > verify ref->u.ss.length in that depth). LGTM =E2=80=93 I am fine with either variant, but I am slightly inclined to removing the gcc_assert* =E2=80=93 as I believe that the existing checks come early enough and do se= em to work well. Can you check ('grep') whether we already have sufficient coverage of substring out of bounds? We presumably have, but if you spot something, I think it makes sense to add those to the testsuite. Tobias *I think GCC won't complain but if ENABLE_ASSERT_CHECKING is not defined, there is then a pointless 'length =3D' assignment, overridden before it is ever used. ----------------- 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