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