From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5E4EC385DC30; Wed, 17 Feb 2021 17:52:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5E4EC385DC30 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: Wed, 17 Feb 2021 17:52:37 +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: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned 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: Wed, 17 Feb 2021 17:52:37 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99122 --- Comment #6 from Martin Jambor --- (In reply to Jakub Jelinek from comment #5) > That could perhaps work for the #c0 testcase where the function actually = has > a non-VL parameter and so garbage in garbage out. > But would that work also for #c2? No, at least not on its own. It leaks struct S, which is local to bar, to the IL of foo, which hits an assert in make_decl_rtl. Einline dump has: struct T b; ... x.1_28 =3D __builtin_alloca_with_align (_26, 8); _20 =3D (long unsigned int) n_14(D); _21 =3D &x.1_28->a; __builtin_memset (_21, 0, _20); b =3D MEM [(struct S *)x.1_28]; > If one dumps the #c2 testcase with -O2 -fno-inline -fdump-tree-optimized, > the PARM_DECL is clearly variable length but not lowered to *ptr, while > in the caller it is lowered that way and allocated through > __builtin_alloca_with_align. > So, clearly PARM_DECLs can be variable length but VAR_DECLs should not be > (they should be gimplified into ptr =3D __builtin_alloca_with_align with = stack > save/restore around the scope and DECL_VALUE_EXPR of *ptr. > The inliner certainly doesn't do that right now. > > For punting on inlining these, I couldn't find any spot that would try to > verify at least remote compatibility of the passed in arguments and the > arguments the callee expects. No, with LTO it would be too late even if we tried to, (IPA) inlining decisions are not meant to be un-doable. The idea was that mismatches are undefined and so we should try our best to emulate non-inlining and not ICE. But apparently we don't manage that now.=