From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 4525B3858D33; Thu, 18 Jan 2024 11:43:13 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4525B3858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705578193;
	bh=17NtxJ7Twv1SIraSw0d8NJdiRtHBAvIygbfhoKsb+Wg=;
	h=From:To:Subject:Date:From;
	b=RnPu57pXvGAe71FIaBSloWcwILeICtaRlFfOuNbQe2PgYJj2SM4sFXk3ZkVqIXb2d
	 MdzawL+P0wo8Zf4sIUzn/YhgfvdZ1BUrjSBS629E2YEyM2o3FF9hzKp1Y6tOIcPQYm
	 AoysTKPsNOvBR8mSGfwo961jhGRsz+PLSepsoCUw=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/113476] New: [14 Regression]
 irange::maybe_resize leaks memory via IPA VRP
Date: Thu, 18 Jan 2024 11:43:12 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-113476-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113476

            Bug ID: 113476
           Summary: [14 Regression] irange::maybe_resize leaks memory via
                    IPA VRP
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see

=3D=3D1854=3D=3D 122,424 bytes in 3 blocks are possibly lost in loss record=
 1,365 of
1,373
=3D=3D1854=3D=3D    at 0x505A1DF: operator new[](unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
=3D=3D1854=3D=3D    by 0x1B8AB58: irange::maybe_resize(int) (value-range.h:=
645)
=3D=3D1854=3D=3D    by 0x1B7C7DF: irange::union_(vrange const&) (value-rang=
e.cc:1451)
=3D=3D1854=3D=3D    by 0x1B1D777: Value_Range::union_(vrange const&)
(value-range.h:705)
=3D=3D1854=3D=3D    by 0x30355A4: ipcp_vr_lattice::meet_with_1(vrange const=
&)
(ipa-cp.cc:1046)
=3D=3D1854=3D=3D    by 0x3035508: ipcp_vr_lattice::meet_with(vrange const&)
(ipa-cp.cc:1

where union_ does

  // At this point, the vector should have i ranges, none overlapping.
  // Now it simply needs to be copied, and if there are too many
  // ranges, merge some.  We wont do any analysis as to what the
  // "best" merges are, simply combine the final ranges into one.
  maybe_resize (i / 2);

and maybe_resize:

inline void
irange::maybe_resize (int needed)
{=20
  if (!m_resizable || m_max_ranges =3D=3D HARD_MAX_RANGES)
    return;

  if (needed > m_max_ranges)
    {
      m_max_ranges =3D HARD_MAX_RANGES;
      wide_int *newmem =3D new wide_int[m_max_ranges * 2];
      unsigned n =3D num_pairs () * 2;
      for (unsigned i =3D 0; i < n; ++i)
        newmem[i] =3D m_base[i];
      m_base =3D newmem;
    }

that looks OK at first right but there's an irange CTOR

inline
irange::irange (wide_int *base, unsigned nranges, bool resizable)

that might end up with unexpected m_base/m_max_ranges here.

Testcase is dwarf2out.i preprocessed from the last release using C but I
guess it's easy to reproduce with any TU from GCC itself.=