https://github.com/CGAL/cgal/pull/4013#issuecomment-507291311
Because of two constructions in Algebraic_curve_kernel_2 and
Hyperbolic_octagon_translation, the assertion "!blocks.empty()" from
`<CGAL/CORE/MemoryPool.h>` was triggered during the destruction of
thread-local objects.
This strange patch ensures that the order of creation of thread-local
object is right, so the order of destruction is right as well.
Because of bug in gcc, even if the C++11 `thread_local` keyword can be
used, it cannot be used for the TLS static member of the class template
`MemoryPool<T>`. That triggers a bug in gcc (tested with g++ 6.3.1):
```
.../include/CGAL/CORE/MemoryPool.h:113:25: error: redefinition of 'bool __tls_guard'
MemoryPool<T, nObjects> MemoryPool<T, nObjects>::memPool;
^~~~~~~~~~~~~~~~~~~~~~~
.../include/CGAL/CORE/MemoryPool.h:113:25: note: 'bool __tls_guard' previously declared here
.../include/CGAL/CORE/MemoryPool.h:113: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/cc4xCWuR.out file, please attach this to your bugreport.
```
The bug seems to be from g++ >= 5:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948
The commit 6c77740485 was not complete:
> CORE MemoryPool<T> has to be destroyed last
>
> If Boost implementation of thread local storage is used, the order of
> destructors is reversed, compared to C++11 `static thread_local`. The
> solution for CORE `MemoryPool<T>` is to make the static variable a
> static member of the class, and initialize the pointer only inside the
> function. That ensures that the destructor will be called after the
> destructor of local static variables.
Actually the explanation about the reverse order is not right, and even
with C++ `thread_local`, we have to ensure that the static data member
of `MemoryPool<T>` is created before any other CORE static variable.
This commit is a followup of the commit
6c7774048521d2779d1657871f476624a46d220b: even in C++11, the `memPool`
variable becomes a thread-local data member, instead of a thread-local
variable at function scope.
Fix#1844.
If Boost implementation of thread local storage is used, the order of
destructors is reversed, compared to C++11 `static thread_local`. The
solution for CORE `MemoryPool<T>` is to make the static variable a
static member of the class, and initialize the pointer only inside the
function. That ensures that the destructor will be called after the
destructor of local static variables.
Sébastien Loriot
Laurent Rineau
Andreas Fabri
Mael Rouxel-Labbé