From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8ABBE3858D33; Tue, 20 Feb 2024 13:51:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8ABBE3858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708437100; bh=I2ut4aKPXwlCcemDmrxUri7spbDRBsfZH+jsumYiRx8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bkNR6u93w8hMnLjKIFZtntintm8ICjLIGpCMB+eo3BqpOpkaEnIHpAckuE0i8fQK3 mKG5BJ85ZuGS11y69HKszkEhhFpn0YyQdj4vBWDdCNBOGTTWV5Xxtu7G5tYK78peqN bnf/YV+ry6X7iovZHp8lm50expHBfK62IE4cdQ68= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/42355] Segmentation fault with -g Date: Tue, 20 Feb 2024 13:51:39 +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: 4.4.2 X-Bugzilla-Keywords: compile-time-hog, memory-hog X-Bugzilla-Severity: minor X-Bugzilla-Who: rguenth 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on cc short_desc 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D42355 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2021-12-09 00:00:00 |2024-2-20 CC| |rguenth at gcc dot gnu.org Summary|Segmentation fault |Segmentation fault with -g --- Comment #15 from Richard Biener --- Re-confirmed. GCC 14 crashed on me after allocating > 30GB of memory at /users/pfoelsch/boost_1_41_0/boost/mpl/joint_view.hpp:44:8: internal compil= er error: Segmentation fault 0xf042a2 crash_signal /space/rguenther/src/gcc-forceslp/gcc/toplev.cc:317 0xefd3c3 ggc_alloc_string(char const*, int) /space/rguenther/src/gcc-forceslp/gcc/stringpool.cc:92 0x8292be pp_ggc_formatted_text(pretty_printer*) /space/rguenther/src/gcc-forceslp/gcc/cp/error.cc:3171 0x8292be decl_as_string(tree_node*, int) /space/rguenther/src/gcc-forceslp/gcc/cp/error.cc:3224 0x8292be decl_as_dwarf_string(tree_node*, int) /space/rguenther/src/gcc-forceslp/gcc/cp/error.cc:3212 0xae0fe4 type_tag /space/rguenther/src/gcc-forceslp/gcc/dwarf2out.cc:22459 0xb0bb08 gen_struct_or_union_type_die /space/rguenther/src/gcc-forceslp/gcc/dwarf2out.cc:26020 ... it seems to be an inherent issue with the way we produce DWARF for the types here, possibly duplicating a lot of long DW_AT_name strings (30GB worth of it). Changing the testcase to have typedef CDer1<8>::type CDer12; typedef CDer< boost::mpl::set< boost::mpl::long_<5>, boost::mpl::long_<4>, boost::mpl::long_<3>, boost::mpl::long_<2>, boost::mpl::long_<1>, boost::mpl::long_<0> > > CDer9; makes it "only" take 3.5GB and finish compiling. You then can see things like <3>: Abbrev Number: 29 (DW_TAG_structure_type) DW_AT_name : (indirect string, offset: 0x629): s_item, boost::mpl::s_item, boost::mpl::set0 > > or <1><18a5>: Abbrev Number: 29 (DW_TAG_structure_type) <18a6> DW_AT_name : (indirect string, offset: 0x1b7f): CDer, boost::mpl::s_item, boost::mpl::s_ite m, boost::mpl::s_item, boost::mpl::s_item, boost::mpl::s_item, boost::mpl::s_item, bo ost::mpl::s_item, boost::mpl::set0 > > > > > > > >, dou ble> and worse. Interestingly enough we still end up throwing most stuff away ending up with just an 20kb object file. So I just guess we're somehow "recursively" building up the above strings, not re-using substrings but exponentially grow memory usage when producing them. There's definitely a cycle involving dump_type and dump_template_argument.=