From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8E3A83959E40; Wed, 2 Dec 2020 07:38:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E3A83959E40 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyBjLzk3MTcyXSBbMTEgUmVncmVzc2lvbl0gSUNFOiB0cmVl?= =?UTF-8?B?IGNvZGUg4oCYc3NhX25hbWXigJkgaXMgbm90IHN1cHBvcnRlZCBpbiBMVE8g?= =?UTF-8?B?c3RyZWFtcyBzaW5jZSByMTEtMzMwMy1nNjQ1MGYwNzM4OGY5ZmU1Nw==?= Date: Wed, 02 Dec 2020 07:38:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: ice-on-valid-code, lto X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 07:38:34 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97172 --- Comment #20 from rguenther at suse dot de --- On Tue, 1 Dec 2020, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97172 >=20 > --- Comment #19 from Jan Hubicka --- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97172 > >=20 > > --- Comment #18 from Martin Sebor --- > > Let me explain how this works. The VLA bounds in function parameters a= re used > > in two ways: > > 1) in the front end, to check function redeclarations involving arrays = and VLAs > > for equivalence, > > 2) in the middle end, to check function calls for out of bounds accesse= s. > >=20 > > As an example of (1) consider the following declarations of function f(= ): > >=20 > > void f (int X, int, int A[X], int B[foo()]); > > and > > void f (int, int J, int A[J], int B[foo() + 1]); > >=20 > > The bounds in the parameters A and B are different and we'd like them > > diagnosed. The bound X is the first parameter in the first declaration= of f > > but J is the second parameter in the second f(). Because the bounds ar= e also > > parameters, we use their positions in the argument list to determine th= at they > > don't match. > >=20 > > Likewise, the bound foo() in B is different from foo() + 1, but because= neither > > is a parameter the only way to determine whether they match is by compa= ring > > them for equivalence. The code uses operand_equal_p(..., OEP_LEXICOGRA= PHIC). > >=20 > > (2) is done only for bounds that are parameters. Other bounds are not = used for > > anything, but they're still stored in the attributes so they can be com= pared in > > the redeclarations. > >=20 > > Since the "complex" bounds aren't used after the front end is done with= them, > > unless there's a way to remove them at some point after the front end i= s done > > (or set them to NULL or something), the LTO streaming code could ignore= them > > instead of asserting on them. Alternatively, instead of storing them i= n their >=20 > free_lang_data should a good place to free them. In general we should > avoid storing things to IL that are not useful to middle end and keep > them there till LTO streaming. Even if it does not make LTO streaming > to ICE it stll consumes memory, disk space and compile time.=20 The frontend needs to make sure no frontend specific tree codes leak into GENERIC so GENERICization is the place where the FE should clear those. FLD is too late and doing it there would be a hack.=