Well, may be x64 edition's 64 bit performance wasn't great either, but probably it's a MinGW thing.
There was another problem, the -iwad parameter didn't work properly (bad iwad search path) with MinGW so iwads could not be launched with ZDL if not in the GZDoom folder but it's fixed now.

hail-to-the-ryzen wrote:

Two issues with the tdm-gcc-32 build:
1. r_multithreaded=1 not working with the SSE2 truecolor software renderer
2. crashes on exit regardless of renderer

For #1, testing with these flags for debug build: -g -mincoming-stack-boundary=2 -msse2 -mfpmath=sse

gcc thread_local destructor cause use after free; https://github.com/Alexpux/MINGW-packages/issues/2519:
"Don't use thread_local on GCC for MinGW targets."

Testing alternatives, such as:
#define thread_local __declspec(thread)

Actually that was discussed in the ZDoom thread linked earlier. I removed thread_local from VMFrameStack GlobalVMStack as Graf suggested and still crashed. That __declspec(thread) thing is for VS and it won't compile with __thread either since that object needs to be allocated dynamically.
So i didn't mention it was a thread local variable in the bug report. Something similar happened with the FMaterial destructor in the old GL renderer (gzdoom32 branch).

Both those changes seem to fix issues 1 and 2. Limited testing.

Which changes? I removed the thread_local keyword before VMFrameStack GlobalVMStack and still crashed here.

It works now with tdm-gcc-32. Working on a W95 static build by an alternative method.

It didn't work for me with tdm-gcc 5.1 on win 8.1. Which OS are you using? About win95 98 already had those timing issues (half the framerate).

I'm trying to pair mingw32 with a lightweight std::thread library. I'll try to reproduce that issue, too.

But it is fixed now or not?
I forgot to mention the GL renderer won't run on win95, there are a lot of win98 function calls, only ancient versions did.
Today i found a tower near a trash container, k6-2 500 on a gigabyte ga-5ax board with a sis 6326, sb pci and a dead hdd. Perhaps i could test there. 😀
Edit: perhaps the crash is cpu speed dependant.

I only tested issues #1 and #2 from above. Here is another method:
https://www.reddit.com/r/cpp/comments/6fitru/ … boost_1640_for/

They describe using boost:🧵

1I see that you are not linking against winpthread like the upstream mingw. How exactly does this work?
2
3Boost.Thread calls the Win32 API directly. I don't know how GCC's thread_local implementation works; possibly they're directly calling the Win32 API too, even as libstdc++ wants to call pthreads.
4
5AFAIK the mingw64 upstream uses gcc's emutls which result in some calls to pthread_key_create and friends, and that is quite buggy.
6
7And that's why I run away screaming from pthreads wrappers.
8
9Which flags do I need to pass to gcc to get whatever configuration you have?
10
11See mingw-w64+gcc.sh on GitHub.
12https://github.com/StephanTLavavej/mingw-distro/blob/master/mingw-w64%2Bgcc.sh

Removing thread_local won't help here. Also that boost solution is not acceptable in GZDoom (neither the hack) but could be in a fork. Anyway that's a 64 bit unofficial build (or repackage) and that's not the recommended way of creating 32 bit executables.
Also the crash on exit in the FMaterial destructor in the GL renderer almost certainly is still there.
Edit: no, that one is gone.
I don't think using a non standard C++ library is a good idea anyway, it would compile only with that distro.

I've removed the thread_local keyword and tried the hack, it works only when also making that variable non thread local.
https://forum.zdoom.org/viewtopic.php?f=4&t=6 … art=15#p1054208

Nice work as always! I had difficulty running the gdb debugger with some debug builds, but I guess that you had no such issue.

Maybe the mingw-w64 and gcc teams will fix any outstanding C++11 threads issues. These seem to have been documented for at least a few years.

Thanks, but i was kidding when i said it was an elegant solution. 🤣 It's just a quick hack to prevent the crash.
Also i've just fixed a couple of bad merges. 😵 I haven't pushed the hack yet becouse i'm waiting for the MinGW-w64 devs but i don't actually think they'll look into it, also i think that thread_local thing is hopeless at least for now.
No problem debugging here but i use Code::Blocks mostly. I usually compile from the command line since the IDE most times won't catch the -j2 parameter.

I think it is an impressive workaround and provides a guide for future instances of that issue. 😀

I recall there was a similar bug reported at zdoom in older versions of *bsd, perhaps openbsd and a recent gcc? If that is true, why does gcc and c++11 threads only work for linux?

The debugger worked for me and then it didn't. 🙁 I was somewhat lax and used MSYS from a mingw32 installation. Edited /etc/fstab so that it pointed to tdm-gcc-32 instead; along with dx9 header files.

You don't need MSYS at all, i use Code::Blocks but compile from the windows command line increasing the buffer for cmd for convenience.
It's better to debug from the IDE. Just remember that in tdm-gcc the debugger is called gdb32 and not just gdb.
Of course i added the path to the MinGW binaries to the system path (editing Path in advanced system properties).
Also i've got MSYS2 installed for MinGW-w64 (but it's not required either).
The DirectX libraries are included in the MinGW package.
I wrote a couple of mini-guides @ https://forum.zdoom.org/viewtopic.php?f=4&t=60338

I've pushed the hack for the crash on exit and updated the MinGW bug report accordingly, it can take them one month to reply.

I went from a GeForce GTX650 down to a GeForce 9800GT and it went from this:

mockingbird wrote:

32-bit build
timed 4848 gametics in 971 realtics (174.7 fps)

To this:
timed 1756 gametics in 860 realtics (71.5 fps)

I think the code below is the cause, or at least one of the causes, of the thread_local issue in mingw-w64. This code is in the libc++ library which then references the libc function __cxa_thread_atexit. Some untested changes are below to instead use a different code path for testing. LLVM handled it with a different solution: https://reviews.llvm.org/D21803.

1--- atexit_thread-Orig.cc	2018-05-19 20:59:35 -0400
2+++ atexit_thread.cc	2018-05-19 21:23:36 -0400
3@@ -25,16 +25,16 @@
4 #include <cstdlib>
5 #include <new>
6 #include "bits/gthr.h"
7-#ifdef _GLIBCXX_THREAD_ATEXIT_WIN32
8+#if 1 // #ifdef _GLIBCXX_THREAD_ATEXIT_WIN32
9 #define WIN32_LEAN_AND_MEAN
10 #include <windows.h>
11 #endif
12 
13-#if _GLIBCXX_HAVE___CXA_THREAD_ATEXIT
14+#if 0 // _GLIBCXX_HAVE___CXA_THREAD_ATEXIT
15 
16 // Libc provides __cxa_thread_atexit definition.
17 
18-#elif _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL
19+#elif 0 // _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL
20 
21 extern "C" int __cxa_thread_atexit_impl (void (*func) (void *),
22 					 void *arg, void *d);
23@@ -55,13 +55,13 @@ namespace {
24     void (*destructor)(void *);
25     void *object;
26     elt *next;
27-#ifdef _GLIBCXX_THREAD_ATEXIT_WIN32
28+#if 1 // #ifdef _GLIBCXX_THREAD_ATEXIT_WIN32
29     HMODULE dll;
30 #endif
31   };
32 
33-  // Keep a per-thread list of cleanups in gthread_key storage.
34-  __gthread_key_t key;
35+  // Keep a per-thread list of cleanups in pthread_key storage.
36+  pthread_key_t key;
37   // But also support non-threaded mode.
38   elt *single_thread;
39 
40@@ -73,7 +73,7 @@ namespace {
41       {
42 	elt *old_e = e;
43 	e->destructor (e->object);
44-#ifdef _GLIBCXX_THREAD_ATEXIT_WIN32
45+#if 1 // #ifdef _GLIBCXX_THREAD_ATEXIT_WIN32
46 	/* Decrement DLL count */
47 	if (e->dll)
48 	  FreeLibrary (e->dll);
49@@ -87,10 +87,10 @@ namespace {
50   void run ()
51   {
52     void *e;
53-    if (__gthread_active_p ())
54+    if (1/*__gthread_active_p ()*/)
55       {
56-	e = __gthread_getspecific (key);
57-	__gthread_setspecific (key, NULL);
58+	e = pthread_getspecific (key);
59+	pthread_setspecific (key, NULL);
60       }

61     else
62       {
63@@ -104,8 +104,8 @@ namespace {
64   // key init/delete rather than atexit so that delete is run on dlclose.
65   void key_init() {
66     struct key_s {
67-      key_s() { __gthread_key_create (&key, run); }
68-      ~key_s() { __gthread_key_delete (key); }
69+      key_s() { pthread_key_create (&key, run); }
70+      ~key_s() { pthread_key_delete (key); }
71     };
72     static key_s ks;
73     // Also make sure the destructors are run by std::exit.
74@@ -120,11 +120,11 @@ __cxxabiv1::__cxa_thread_atexit (void (*
75   _GLIBCXX_NOTHROW
76 {
77   // Do this initialization once.
78-  if (__gthread_active_p ())
79+  if (1/*__gthread_active_p ()*/)
80     {
81-      // When threads are active use __gthread_once.
82-      static __gthread_once_t once = __GTHREAD_ONCE_INIT;
83-      __gthread_once (&once, key_init);
84+      // When threads are active use pthread_once.
85+      static pthread_once_t once = PTHREAD_ONCE_INIT;
86+      pthread_once (&once, key_init);
87     }
88   else
89     {
90@@ -138,8 +138,8 @@ __cxxabiv1::__cxa_thread_atexit (void (*
91     }
92 
93   elt *first;
94-  if (__gthread_active_p ())
95-    first = static_cast<elt*>(__gthread_getspecific (key));
96+  if (1/*__gthread_active_p ()*/)
97+    first = static_cast<elt*>(pthread_getspecific (key));
98   else
99     first = single_thread;
100 
101@@ -149,7 +149,7 @@ __cxxabiv1::__cxa_thread_atexit (void (*
102   new_elt->destructor = dtor;
103   new_elt->object = obj;
104   new_elt->next = first;
105-#ifdef _GLIBCXX_THREAD_ATEXIT_WIN32
106+#if 1 // #ifdef _GLIBCXX_THREAD_ATEXIT_WIN32
107   /* Store the DLL address for a later call to FreeLibrary in new_elt and
108      increment DLL load count.  This blocks the unloading of the DLL
109      before the thread-local dtors have been called.  This does NOT help
110@@ -158,8 +158,8 @@ __cxxabiv1::__cxa_thread_atexit (void (*
111 		      (LPCWSTR) dtor, &new_elt->dll);
112 #endif
113 
114-  if (__gthread_active_p ())
115-    __gthread_setspecific (key, new_elt);
116+  if (1/*__gthread_active_p ()*/)
117+    pthread_setspecific (key, new_elt);
118   else
119     single_thread = new_elt;
120