I think we need to revert this.

I got this email from linaro/gcc-regressions:

[Linaro-TCWG-CI] gcc-15-1649-g19f630e6ae8d: FAIL: 2 regressions on aarch64

regressions.sum: === gcc tests ===

Running gcc:gcc.misc-tests/gcov.exp ... FAIL: gcc.misc-tests/gcov-23.c (internal compiler error: in operator[], at vec.h:910) FAIL: gcc.misc-tests/gcov-23.c (test for excess errors)

This did not reproduce on my machine, but I took a quick look at the hash-map implementation. hash_map.put calls hash_table.find_slot_with_hash, which calls hash_table.expand, which does move+destroy. auto_vec is not really move-aware which leads to a double-free.

The fix is either to make auto_vec move-aware (and more like C++'s std::vector) or revert this patch and apply the original version with an explicit release.

OK?

Thanks, Jørgen

On 6/25/24 12:23, Jan Hubicka wrote:

...

The value vec objects are destroyed on exit, but release still needs to be called explicitly.

gcc/ChangeLog:

• tree-profile.cc (find_conditions): Release vectors before return.

I wonder if you turn hash_map<int_hash<unsigned, 0>, vec<basic_block>> exprs; to hash_map<int_hash<unsigned, 0>, auto_vec<basic_block>> exprs; Won't hash_map destructor take care of this by itself?

Honza

...

---

gcc/tree-profile.cc | 3 +++ 1 file changed, 3 insertions(+)

diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc index e4bb689cef5..18f48e8d04e 100644 --- a/gcc/tree-profile.cc +++ b/gcc/tree-profile.cc @@ -919,6 +919,9 @@ find_conditions (struct function *fn) if (!have_post_dom) free_dominance_info (fn, CDI_POST_DOMINATORS);

• for (auto expr : exprs)

•  expr.second.release ();
  

• cov->m_masks.safe_grow_cleared (2 * cov->m_index.last ());
  const size_t length = cov_length (cov);
  for (size_t i = 0; i != length; i++)
  

-- 2.39.2