From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2922E393BC38; Fri, 19 Feb 2021 10:31:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2922E393BC38 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733 Date: Fri, 19 Feb 2021 10:31:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.3 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: Fri, 19 Feb 2021 10:31:03 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99122 --- Comment #19 from Martin Jambor --- (In reply to Richard Biener from comment #17) > there's variably_modified_type_p (you can pass NULL_TREE for the fndecl) > which is more to the point. Otherwise it looks reasonable. Does IPA CP > do things like IPA SRA and split aggregates? No, it does not split them, the only SRAish thing it does is simple removal of unused register-type parameters. > I wonder in which cases IPA CP would derive "constants" for > aggregates, so why are aggregate parameters even tracked? I am not sure I understand the question. The testcase in comment #12 attempts to pass a simple double constant to what is actually a VLA structure, causing an ICE on undefined behavior input, which is the main thing I want to avoid. But I have just realized that if we now insist that we know all types anyway - I have run the whole C testsuite and did not find any K&R testcase where IPA-CP would consider a parameter for propagation when not knowing its type - we can do something better and only propagate when we know that force_value_to_type would not resort to building a zero constructor. This will allow to still propagate ("aggregate") constants within VLAs like if there was one in b.n in the testcase (and the caller was somewhat saner). > I am testing the following for the inline issue for the last testcase, > leaving the IPA CP one to you. Sure, thanks.=