Work around a MinGW thread_local bug

MinGW-w64 generates bad code when accessing extern thread_local objects.
Wrapper functions are used to ensure it only accesses them from the same place
they're defined. This unfortunately adds a bit of overhead for what should be a
relatively simple thing.

These functions are inlined for non-MinGW targets, avoiding the overhead on
non-affected targets.

1 files changed, 15 insertions, 0 deletions

diff --git a/alc/context.h b/alc/context.h
index d0afbdd9..87754235 100644
--- a/alc/context.h
+++ b/alc/context.h
@@ -131,8 +131,10 @@ struct ALCcontext : public al::intrusive_ref<ALCcontext>, ContextBase {
     /* Process-wide current context */
     static std::atomic<ALCcontext*> sGlobalContext;
 
+private:
     /* Thread-local current context. */
     static thread_local ALCcontext *sLocalContext;
+
     /* Thread-local context handling. This handles attempting to release the
      * context which may have been left current when the thread is destroyed.
      */
@@ -143,6 +145,19 @@ struct ALCcontext : public al::intrusive_ref<ALCcontext>, ContextBase {
     };
     static thread_local ThreadCtx sThreadContext;
 
+public:
+    /* HACK: MinGW generates bad code when accessing an extern thread_local
+     * object. Add a wrapper function for it that only accesses it where it's
+     * defined.
+     */
+#ifdef __MINGW32__
+    static ALCcontext *getThreadContext() noexcept;
+    static void setThreadContext(ALCcontext *context) noexcept;
+#else
+    static ALCcontext *getThreadContext() noexcept { return sLocalContext; }
+    static void setThreadContext(ALCcontext *context) noexcept { sThreadContext.set(context); }
+#endif
+
     /* Default effect that applies to sources that don't have an effect on send 0. */
     static ALeffect sDefaultEffect;