https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #6 from lh_mouse <lh_mouse at 126 dot com> --- (In reply to Markus Trippelsdorf from comment #5) > (In reply to lh_mouse from comment #4) > > (In reply to Jonathan Wakely from comment #3) > > > OK, whatever weird definition of leak you are using is irrelevant. The > > > memory is still in use until the program exits, and there is still a > > > pointer > > > to it. It is not lost, or forgotten about, it is in use by the run-time. > > > > That is an ostrich strategy. > > > > The runtime is amenable for deallocation of the pool because it is the > > runtime that has allocated the pool. The runtime shall free it, by > > definition, when it is no longer 'in use by the run-time', but not never. > > See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 > for further motivation. I did read those posts but fail to get what the last post meant: > Of course that's broken in older releases as well because of the > emergency_mutex being dynamically constructed. Also if the order of global ctors is essential I would suggest a standalone ctor and dtor: namespace { char *arena; size_t arena_size; __attribute__((__constructor__(65535))) void area_ctor(){ // perform initialization here... } __attribute__((__destructor__(1))) void area_dtor(){ // ... and perform cleanup here. } }
