To my dismay i discovered that the eh_shmem.patch cannot be applied if building gcc with aslr (segfaults in gnattools and even if skipping gnat it will segfault to no end on even the simplest hello world example).

I suspect that it relies on set base adresses and does not play well with the dynamic base address feature from aslr, unfortunatly i have no idea how to fix this.

removing the patch gets around the problem but then we cannot throw exceptions across dll boundaries so its quite a conondrum.

Any ideas ?

cd "c:\Users\nihao\dock_menu\code\SJJG\Structure" ; if ($?) { gcc *.c -o structure.exe } ; if ($?) { .\structure.exe }
gcc.exe: error: *.c: Invalid argument
gcc.exe: fatal error: no input files
compilation terminated.

I came to report an error with the library
The only one I can't use in version 9.2.0
Whenever I import the library, these errors appear when trying to compile.
I love the ease of use of this compiler and the highlights, I hope I helped to find the error.

In file included from C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/system_error:39,
from C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/bits/ios_base.h:46,
from C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/ios:42,
from C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/ostream:38,
from C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/iostream:39,
from C:\Users\gmore\OneDrive\�rea de Trabalho\Fatorial.cpp:1:
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:53:25: error: 'EBADMSG' was not declared in this scope; did you mean 'EBADF'?
53 | bad_message = EBADMSG,
| ^~~~~~~
| EBADF
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:71:31: error: 'EIDRM' was not declared in this scope
71 | identifier_removed = EIDRM,
| ^~~~~
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:89:21: error: 'ENOLINK' was not declared in this scope; did you mean 'EMLINK'?
89 | no_link = ENOLINK,
| ^~~~~~~
| EMLINK
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:93:33: error: 'ENODATA' was not declared in this scope
93 | no_message_available = ENODATA,
| ^~~~~~~
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:103:32: error: 'ENOSR' was not declared in this scope; did you mean 'ENOSPC'?
103 | no_stream_resources = ENOSR,
| ^~~~~
| ENOSPC
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:112:26: error: 'ENOSTR' was not declared in this scope; did you mean 'ENOTTY'?
112 | not_a_stream = ENOSTR,
| ^~~~~~
| ENOTTY
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:139:34: error: 'ENOTRECOVERABLE' was not declared in this scope
139 | state_not_recoverable = ENOTRECOVERABLE,
| ^~~~~~~~~~~~~~~
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:142:28: error: 'ETIME' was not declared in this scope
142 | stream_timeout = ETIME,
| ^~~~~
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/9.2.0/include/c++/x86_64-w64-mingw32/bits/error_constants.h:145:28: error: 'ETXTBSY' was not declared in this scope
145 | text_file_busy = ETXTBSY,
| ^~~~~~~

does not happen with normal mingw-w64 64 bit ?!?, also tried linking with the dynamic runtimes instead using -shared-libgcc -shared-libstdc++ but same problem.

Welcome back m8 :)

The mingw32-float.h.patch gets circumvented by changes to gcc's build chain which now uses a sed script to do allmost the same as your patch, so we end up with two #include_next<float.h>.

One from your patch and another unguarded one from the sed script.

`#if defined (MINGW32) && ! defined (MINGW_FLOAT_H)
/* MinGW.org's runtime libraries provide a supplementary float.h, which

• must also be included to complement this one. Ideally that MinGW.org
• header should be included first, and it will include this one, but in
• a default configuration it doesn't normally happen this way; when we
• didn't see it first, include the MinGW.org header now!
  */

include_next <float.h>

#endif

#endif /* FLOAT_H__ */
#include_next <float.h>`

I tried to compile the last svn codeblocks version (12458) with your tdm gcc 10.3 version, 64 bits on windows 10.
I have 2 problems with that:

• My antivirus software McAfee declare that the executable codeblocks.exe contains a virus Real Protect-SSI2EA3B..., certainly a false positive but it's annoying (I can tell McAfee to ignore this file).
• The other problem is not specific to your version, but affects the functionality of Codeblocks. Its has been described on the C::B forum in https://forums.codeblocks.org/index.php/topic,24486.0.html : it appeared with gcc 10.2 in january/february 2021, may be related to binutils 2.36, but I'm not sure. It's certainly a codeblocks problem but until now not solved.

Thanks for your work
Gerard

uncoupled the shmem patch even more using inline asembly for memset and memcpy, also added a better debugbreak.
cleaned it up some also and changed the single threaded TLS code to only be used when linking to the static runtimes.
patch here is for gcc-11.2.0 and works rather well, i also changed the internal logic in gcc.c to work without libgcc_eh.a, take a glance at the patch to see what i mean.
0160-tdm-shared-memory-unwinder.zip

When I compile several .cpp files to .exe files, a huge bug comes up. File after tdm-gcc compilation is about 3000kb,. File after mingw64 compilation is about 100kb. Then I do a careful comparison between these, I found tdm-gcc .exe are 3000kb exactly bigger than mingw64 .exe (only a slice error). It looks as if it has something to do with strip, but the .exe after strip is still 900kb, still too huge comparing to mingw64.exe