https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
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
==1854== 122,424 bytes in 3 blocks are possibly lost in loss record 1,365 of
1,373
==1854== at 0x505A1DF: operator new[](unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1854== by 0x1B8AB58: irange::maybe_resize(int) (value-range.h:645)
==1854== by 0x1B7C7DF: irange::union_(vrange const&) (value-range.cc:1451)
==1854== by 0x1B1D777: Value_Range::union_(vrange const&)
(value-range.h:705)
==1854== by 0x30355A4: ipcp_vr_lattice::meet_with_1(vrange const&)
(ipa-cp.cc:1046)
==1854== 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)
{
if (!m_resizable || m_max_ranges == HARD_MAX_RANGES)
return;
if (needed > m_max_ranges)
{
m_max_ranges = HARD_MAX_RANGES;
wide_int *newmem = new wide_int[m_max_ranges * 2];
unsigned n = num_pairs () * 2;
for (unsigned i = 0; i < n; ++i)
newmem[i] = m_base[i];
m_base = 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.
