https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mliska at suse dot cz
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Too much C++ here I guess?
==16301== by 0x14DCE52:
mem_alloc_description<pool_usage>::~mem_alloc_description() (mem-stats.h:559)
vs.
==16301== by 0x8427C4: base_pool_allocator<memory_block_pool>::release()
(alloc-pool.h:311)
==16301== by 0x84299D:
base_pool_allocator<memory_block_pool>::~base_pool_allocator()
(alloc-pool.h:335)
==16301== by 0x8E25D3: object_allocator<et_occ>::~object_allocator()
(alloc-pool.h:474)
where the latter calls release_instance_overhead.
extern mem_alloc_description<pool_usage> pool_allocator_usage;
comes from alloc-pool.c. Looks like when linking LTO we get the bad destructor
order (by luck?).
Leaking pool_allocator_usage will fix this (making it a reference). A very
bit ugly though.
Index: gcc/alloc-pool.c
===================================================================
--- gcc/alloc-pool.c (revision 233633)
+++ gcc/alloc-pool.c (working copy)
@@ -24,7 +24,7 @@ along with GCC; see the file COPYING3.
#include "alloc-pool.h"
ALLOC_POOL_ID_TYPE last_id;
-mem_alloc_description<pool_usage> pool_allocator_usage;
+mem_alloc_description<pool_usage> &pool_allocator_usage = *(new
mem_alloc_description<pool_usage>);
/* Output per-alloc_pool memory usage statistics. */
void
Index: gcc/alloc-pool.h
===================================================================
--- gcc/alloc-pool.h (revision 233633)
+++ gcc/alloc-pool.h (working copy)
@@ -95,7 +95,7 @@ struct pool_usage: public mem_usage
const char *m_pool_name;
};
-extern mem_alloc_description<pool_usage> pool_allocator_usage;
+extern mem_alloc_description<pool_usage> &pool_allocator_usage;
#if 0
/* If a pool with custom block size is needed, one might use the following
