From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 67A5A3858D33; Wed, 21 Feb 2024 09:16:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67A5A3858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708506960; bh=KlTbtv8vK7f7DpLSI9PGZxzdjx7GrFW6bjiolF318mY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PFbhEybUY5EIVYGdtyQfqU3QL+1E7OzdG2M4GVNiSQGuysL6H/tmNu1ljyq8VBSuo 9l8VlGHcfh+YZIMiVTigtjRN9QGGM9jO4TqDLgCPMaHp0EjQuoI7qZtaO2b9yOA2dc qqrdvETgXNv3lQCkQbVAR7Y7+I6BCYrJTgUdCBso= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP Date: Wed, 21 Feb 2024 09:15:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jamborm at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113476 --- Comment #7 from Aldy Hernandez --- Let me see if I can untangle things here. Thanks for chasing this down, BTW. Value_Range doesn't need a CTOR because it has an int_range_max which does have one (courtesy of int_range<>), so things get initialized correctly. Deleting a memory allocated container that has a Value_Range also works, because of the ~int_range<> destructor: + { + struct container + { + Value_Range vr; + }; + struct container *pointer =3D new container; + pointer->vr.set_type (integer_type_node); + for (int i =3D 0; i < 100; i +=3D 5) + { + int_range<1> tmp (integer_type_node, + wi::shwi (i, TYPE_PRECISION (integer_type_node)), + wi::shwi (i+1, TYPE_PRECISION (integer_type_node)= )); + pointer->vr.union_ (tmp); + } + delete pointer; Deleting pointer causes us to call int_range::~int_range() which clean things appropriately. So it looks like the problem is the missing destructor in IPA. That being said, there's a few things I've noticed thanks to you guys' analysis. First, the virtual marker in the int_range<> destructor is not needed. IPA + ranges went through various changes this release, and I believe that was left over from when value_range (int_range<2>) was being placed in GC space directly. We went through various incantations this release wrt IPA storage of ranges, both in GC and in the stack. Ultimately we ended up with ipa_vr, which I believe is the only use of ranges in GC space, and furthermore it uses vrange_storage not vrange nor irange nor anything else. For that matter, vrange_storage doesn't even have pointers, so we shouldn't need GTY markers at all. It seems that since IPA is the only GC user of iranges, I think we can safely remove GTY support from the entire vrange hierarchy. The rule of thumb should be that only int_range<> and derivatives should be in short-term storage, and GC users should use vrange_storage (like ipa_vr is doing, or perhaps vrange_allocator which automates the allocation).=