[Bug middle-end/69919] pool allocator and mem-stat race at program exit

2016-02-25 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Martin Liška  ---
Fixed in trunk.

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

2016-02-25 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu Feb 25 16:57:39 2016
New Revision: 233722

URL: https://gcc.gnu.org/viewcvs?rev=233722=gcc=rev
Log:
Do not gather mem stats in run_exit_handles (PR

PR middle-end/69919
* alloc-pool.c (after_memory_report): New variable.
* alloc-pool.h (base_pool_allocator ::release): Do not use
the infrastructure if after_memory_report.
* toplev.c (toplev::main): Mark after memory report.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/alloc-pool.c
trunk/gcc/alloc-pool.h
trunk/gcc/toplev.c

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

2016-02-24 Thread rguenther at suse dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 24 Feb 2016, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919
> 
> --- Comment #3 from Martin Liška  ---
> Created attachment 37782
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37782=edit
> Suggested patch
> 
> Well, the situation is not so easy. Ideally, I would set m_reverse_map = NULL
> in
> mem_alloc_description::~mem_alloc_description () and guard
> release_object_overhead and release_instance_overhead with probes if m_* !=
> NULL.
> 
> But as the assignment in the dtor is optimized out by DSE, because it's
> undefined to check member of a destroyed instance.
> 
> Thus I suggest a small work-around that can survive lto.exp and LTO bootstrap
> goes to stage3 (still running).
> 
> What do you think about it?

I guess it'll work.

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

2016-02-24 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919

--- Comment #3 from Martin Liška  ---
Created attachment 37782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37782=edit
Suggested patch

Well, the situation is not so easy. Ideally, I would set m_reverse_map = NULL
in
mem_alloc_description::~mem_alloc_description () and guard
release_object_overhead and release_instance_overhead with probes if m_* !=
NULL.

But as the assignment in the dtor is optimized out by DSE, because it's
undefined to check member of a destroyed instance.

Thus I suggest a small work-around that can survive lto.exp and LTO bootstrap
goes to stage3 (still running).

What do you think about it?

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

2016-02-23 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919

--- Comment #2 from Richard Biener  ---
Or maybe simply making mem_alloc_description::~mem_alloc_description () empty.

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

2016-02-23 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69919

Richard Biener  changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #1 from Richard Biener  ---
Too much C++ here I guess?

==16301==by 0x14DCE52:
mem_alloc_description::~mem_alloc_description() (mem-stats.h:559)

vs.

==16301==by 0x8427C4: base_pool_allocator::release()
(alloc-pool.h:311)
==16301==by 0x84299D:
base_pool_allocator::~base_pool_allocator()
(alloc-pool.h:335)
==16301==by 0x8E25D3: object_allocator::~object_allocator()
(alloc-pool.h:474)

where the latter calls release_instance_overhead.

extern mem_alloc_description 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_allocator_usage;
+mem_alloc_description _allocator_usage = *(new
mem_alloc_description);

 /* 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_allocator_usage;
+extern mem_alloc_description _allocator_usage;

 #if 0
 /* If a pool with custom block size is needed, one might use the following