[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:43f4d44bebd63b354f8798fcef512d4d2b42c655 commit r15-6941-g43f4d44bebd63b354f8798fcef512d4d2b42c655 Author: Jakub Jelinek Date: Thu Jan 16 09:17:50 2025 +0100 vec.h: Properly destruct elements in auto_vec auto storage [PR118400] For T with non-trivial destructors, we were destructing objects in the vector on release only when not using auto storage of auto_vec. The following patch calls truncate (0) instead of m_vecpfx.m_num clearing, and truncate takes care of that destruction: unsigned l = length (); gcc_checking_assert (l >= size); if (!std::is_trivially_destructible ::value) vec_destruct (address () + size, l - size); m_vecpfx.m_num = size; 2025-01-16 Jakub Jelinek PR ipa/118400 * vec.h (vec::release): Call m_vec->truncate (0) instead of clearing m_vec->m_vecpfx.m_num.
[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 --- Comment #7 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #6) > Maybe use > >m_vec->truncate (0); >return; > > for simplicity? Then I'll have to retest ;) But I agree it is simpler that way.
[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
--- Comment #6 from rguenther at suse dot de ---
On Tue, 14 Jan 2025, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
>
> --- Comment #5 from Jakub Jelinek ---
> So I think we want
> 2025-01-14 Jakub Jelinek
>
> PR ipa/118400
> * vec.h (vec::release): Call vec_destruct
> in the using_auto_storage () case.
>
> --- gcc/vec.h.jj2025-01-02 11:23:13.144563938 +0100
> +++ gcc/vec.h 2025-01-14 19:44:59.105506682 +0100
> @@ -2020,6 +2020,8 @@ vec::release (void)
>
>if (using_auto_storage ())
> {
> + if (!std::is_trivially_destructible ::value)
> + vec_destruct (m_vec->address (), m_vec->length ());
>m_vec->m_vecpfx.m_num = 0;
>return;
> }
> Fixes the leak for me, will test tonight.
Maybe use
m_vec->truncate (0);
return;
for simplicity?
[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
--- Comment #5 from Jakub Jelinek ---
So I think we want
2025-01-14 Jakub Jelinek
PR ipa/118400
* vec.h (vec::release): Call vec_destruct
in the using_auto_storage () case.
--- gcc/vec.h.jj2025-01-02 11:23:13.144563938 +0100
+++ gcc/vec.h 2025-01-14 19:44:59.105506682 +0100
@@ -2020,6 +2020,8 @@ vec::release (void)
if (using_auto_storage ())
{
+ if (!std::is_trivially_destructible ::value)
+ vec_destruct (m_vec->address (), m_vec->length ());
m_vec->m_vecpfx.m_num = 0;
return;
}
Fixes the leak for me, will test tonight.
[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
--- Comment #4 from Jakub Jelinek ---
This looks like a serious vec.h bug to me.
avals->m_known_value_ranges member is auto_vec.
ipa-fnsummary.cc does on that
if (!avals->m_known_value_ranges.length ())
{
avals->m_known_value_ranges.safe_grow_cleared
(count,
true);
for (int i = 0; i < count; ++i)
avals->m_known_value_ranges[i].set_type
(void_type_node);
}
avals->m_known_value_ranges[i] = vr;
count seems to be 4, so it uses the auto storage, and safe_gro_cleared there
vec_default_construct constructs 4 objects.
But ~auto_vec calls
this->release ();
and that does
template
inline void
vec::release (void)
{
if (!m_vec)
return;
if (using_auto_storage ())
{
m_vec->m_vecpfx.m_num = 0;
return;
}
va_heap::release (m_vec);
}
where va_heap::release does
if (!std::is_trivially_destructible ::value)
vec_destruct (v->address (), v->length ());
but for the using_auto_storage case we don't do that.
[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 Jakub Jelinek changed: What|Removed |Added Summary|[14/15 Regression] memory |[14/15 Regression] memory |leak of irange at |leak of irange at |evaluate_properties_for_edg |evaluate_properties_for_edg |e (ipa-fnsummary.cc:690)|e (ipa-fnsummary.cc:690) ||since r14-2121 CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r14-2121-g3c52dff792878306515056ecd94c8aa909f388fb
[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 Richard Biener changed: What|Removed |Added Summary|memory leak of irange at|[14/15 Regression] memory |evaluate_properties_for_edg |leak of irange at |e (ipa-fnsummary.cc:690)|evaluate_properties_for_edg ||e (ipa-fnsummary.cc:690) Target Milestone|--- |14.3 Known to work||14.2.1, 15.0 Known to fail||13.3.1 Last reconfirmed||2025-01-12 Priority|P3 |P2 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I'm a bit lost in the woods of range classes, not to say in the object lifetime of IPA stuff so leaving this to others. I do remember similar leaks during GCC 14 development, this particular leak also shows on the GCC 14 branch, same preprocessed source. The GCC 13 branch also has various irange leaks on the reduced testcase but not this specific one, so marking as regression.
