From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D60243896C02; Mon, 30 Nov 2020 21:02:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D60243896C02 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyBjLzk3MTcyXSBbMTEgUmVncmVzc2lvbl0gSUNFOiB0cmVl?= =?UTF-8?B?IGNvZGUg4oCYc3NhX25hbWXigJkgaXMgbm90IHN1cHBvcnRlZCBpbiBMVE8g?= =?UTF-8?B?c3RyZWFtcyBzaW5jZSByMTEtMzMwMy1nNjQ1MGYwNzM4OGY5ZmU1Nw==?= Date: Mon, 30 Nov 2020 21:02:26 +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: hubicka at ucw dot cz 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: Mon, 30 Nov 2020 21:02:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97172 --- Comment #15 from Jan Hubicka --- > I'm not sure I understand correctly what you mean by "avoiding the attrib= ute > for VLA types would likely also be good (are those handled in any reasona= ble > way?)" As I explain in the thread at the link above, the attribute is st= rictly > only strictly necessary for the most significant bound of a VLA parameter= . The > other bounds are encoded in the type and so don't also need to be duplica= ted in > the attribute (it's just more convenient/faster that way). But even with= that > change, and with the unsharing (or with the SAVE_EXPR around it), I'd ex= pect > the most significant bound to still be a problem for the streamer since i= t will > still contain the unsupported nodes. Not SSA_NAMEs but some of the other= s. What kind of other nodes you see? Basically everything that makes sense out of the function body can be streamed. You can not refer also to local scopes of the function, ipa-prop has unshare_expr_without_location=