From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 8FD663857009; Tue, 1 Dec 2020 16:16:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8FD663857009 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 125EF281179; Tue, 1 Dec 2020 17:16:11 +0100 (CET) Date: Tue, 1 Dec 2020 17:16:11 +0100 From: Jan Hubicka To: "msebor at gcc dot gnu.org" Cc: gcc-bugs@gcc.gnu.org Subject: Re: [Bug c/97172] [11 =?utf-8?Q?Regression?= =?utf-8?B?XSBJQ0U6IHRyZWUgY29kZSDigJhzc2FfbmFtZeKAmSBp?= =?utf-8?Q?s?= not supported in LTO streams since r11-3303-g6450f07388f9fe57 Message-ID: <20201201161611.GB95290@kam.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Tue, 01 Dec 2020 16:16:14 -0000 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 > > --- Comment #18 from Martin Sebor --- > Let me explain how this works. The VLA bounds in function parameters are 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 accesses. > > As an example of (1) consider the following declarations of function f(): > > void f (int X, int, int A[X], int B[foo()]); > and > void f (int, int J, int A[J], int B[foo() + 1]); > > 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 are also > parameters, we use their positions in the argument list to determine that they > don't match. > > 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 comparing > them for equivalence. The code uses operand_equal_p(..., OEP_LEXICOGRAPHIC). > > (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 compared in > the redeclarations. > > 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 is 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 in their 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. Honza > tree form they could be stored as strings instead. I list these in the order > of my preference for GCC 11.