Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: TDragon on June 28, 2015, 07:17:37 pm

Title: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: TDragon on June 28, 2015, 07:17:37 pm
I was going to wait for the 5.2.0 upstream release next month, but this build went so smoothly that I figured I'd go ahead and release a little sooner! It's time for...

TDM-GCC 5.1.0 and TDM-GDB 7.9.1
GCC's usual upstream improvements (https://gcc.gnu.org/gcc-5/changes.html), some minor patches, plus 32-bit and 64-bit GDB including Python and auto-loading C++ pretty printers.

TDM-GCC 5.1.0, the first TDM release in the GCC 5 series, is now available for download. As always, I've tested it on wxWidgets (2.8.12) and Code::Blocks SVN (10348) to ensure good compatibility. When building wxWidgets as a MONOLITHIC DLL, you will probably need to use the "-fno-keep-inline-dllexport" flag (mingw32-make ... CXXFLAGS="-fno-keep-inline-dllexport").

Some TDM-specific changes since the last release:

TDM-GCC comes in TWO editions:
You can choose between the classic TDM 32-bit edition and the TDM64 edition. The TDM64 edition is based on the MinGW-w64 runtime API and the x86_64-w64-mingw32 GCC target, and can create both 32-bit and 64-bit code, with the "-m32"/"-m64" compiler flags. Please never mix 32-bit object files (.o), libraries (.a), DLLs, or EXEs with 64-bit versions, and don't report it as a bug if you inadvertently do.

More information and downloads are available at <http://tdm-gcc.tdragon.net/ (http://tdm-gcc.tdragon.net/)>. TDM-GCC includes support for C, C++, Fortran, Objective-C/C++, and Ada, as well as support for the OpenMP multithreading extensions, packaged in a simple Windows installer.

Disclaimer:
As always, please remember:

Cheers,
John E. / TDM
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: stahta01 on June 28, 2015, 08:42:50 pm
Did you apply the PCH fix that was posted somewhere in a CB forum?

Edit: Link to post http://forums.codeblocks.org/index.php/topic,18568.msg138329.html#msg138329 (http://forums.codeblocks.org/index.php/topic,18568.msg138329.html#msg138329)

Tim S.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: scarphin on June 28, 2015, 09:32:37 pm
tdm-gcc is somehow less vulnerable to that bug, I suspect tdragon has already fixed that in his own builds (way before 5.1) or am I wrong?
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: stahta01 on June 28, 2015, 09:34:06 pm
tdm-gcc is somehow less vulnerable to that bug, I suspect tdragon has already fixed that in his own builds (way before 5.1) or am I wrong?

It was NOT fixed in his 4.8 GCC based release. I do NOT remember if I tested the 4.9 based release for the bug or not.

Tim S.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: stahta01 on June 28, 2015, 10:28:34 pm
Patch I am trying for building wxWidgets 3.0.2.
Edit: Building on Windows 7 32 bit.

In file pthread.h replaced below
Code
  struct timespec {
  time_t  tv_sec;   /* Seconds */
  long    tv_nsec;  /* Nanoseconds */
};

with
Code
#define _FAKE_TIME_H_SOURCED	1
#define __need_struct_timespec 1
#include <parts/time.h>

// struct timespec {
//  time_t  tv_sec;   /* Seconds */
//  long    tv_nsec;  /* Nanoseconds */
// };

Tim S.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: stahta01 on June 29, 2015, 02:16:38 am
tdm-gcc is somehow less vulnerable to that bug, I suspect tdragon has already fixed that in his own builds (way before 5.1) or am I wrong?

It was NOT fixed in his 4.8 GCC based release. I do NOT remember if I tested the 4.9 based release for the bug or not.

Tim S.

The PCH bug still exists in "5.1.0 - 2015-06-28" release.

Tim S.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: ollydbg on June 29, 2015, 02:36:40 am
I can hack(binary edit) the cc1plus.exe, and upload it. Do you need that?
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: stahta01 on June 29, 2015, 02:51:25 am
I can hack(binary edit) the cc1plus.exe, and upload it. Do you need that?

I do NOT need it; I am hoping the bug was fixed.

If you can post a patch it might speed up the fix by upstream people be it TDM, MinGW, or MinGW64.

Tim S.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: ollydbg on June 29, 2015, 03:02:56 am
OK. There is a patch in gcc bugzilla posted by other people days ago which is said  better than my merhod.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: TDragon on June 29, 2015, 05:13:18 am
Why are those pthread.h changes needed for wxWidgets?

I hadn't seen that PCH patch before; so, it's not present in the 5.1.0 release.

-John E. / TDM
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: stahta01 on June 29, 2015, 06:16:16 am
Why are those pthread.h changes needed for wxWidgets?

I hadn't seen that PCH patch before; so, it's not present in the 5.1.0 release.

-John E. / TDM

Some reason two different defines of the struct timespec was seen.
So, I changed the one in pthread.h to use the one defined in parts/time.h.

The one in parts/time.h matches the one used by time.h and parts/time.h is included by the header unistd.h.

So, if you include pthread.h and parts/time.h you get an error.

I removed my change and this is the error it stops on while building wxWidgets 3.0.2 using 32 bit TDM GCC.
Code
g++ -c -o gcc_mswudll51Xsjlj\monodll_file.o  -O2 -mthreads  -DHAVE_W32API_H -D__
WXMSW__   -DNDEBUG    -D_UNICODE  -I..\..\lib\gcc_dll51Xsjlj\mswu -I..\..\includ
e  -W -Wall -DWXBUILDING -I..\..\src\tiff\libtiff -I..\..\src\jpeg -I..\..\src\p
ng -I..\..\src\zlib -I..\..\src\regex -I..\..\src\expat\lib -I..\..\src\stc\scin
tilla\include -I..\..\src\stc\scintilla\lexlib -I..\..\src\stc\scintilla\src -D_
_WX__ -DSCI_LEXER -DLINK_LEXERS -DwxUSE_BASE=1 -DWXMAKINGDLL   -Wno-ctor-dtor-pr
ivacy -Wmissing-include-dirs -std=gnu++11 -Wno-unused-local-typedefs -fno-keep-i
nline-dllexport -MTgcc_mswudll51Xsjlj\monodll_file.o -MFgcc_mswudll51Xsjlj\monod
ll_file.o.d -MD -MP ../../src/common/file.cpp
In file included from C:/Apps32/TDM-GCC5_1x-32/lib/gcc/mingw32/5.1.0/include/c++
/mingw32/bits/gthr-default.h:34:0,
                 from C:/Apps32/TDM-GCC5_1x-32/lib/gcc/mingw32/5.1.0/include/c++
/mingw32/bits/gthr.h:148,
                 from C:/Apps32/TDM-GCC5_1x-32/lib/gcc/mingw32/5.1.0/include/c++
/ext/atomicity.h:35,
                 from C:/Apps32/TDM-GCC5_1x-32/lib/gcc/mingw32/5.1.0/include/c++
/bits/basic_string.h:39,
                 from C:/Apps32/TDM-GCC5_1x-32/lib/gcc/mingw32/5.1.0/include/c++
/string:52,
                 from ..\..\include/wx/stringimpl.h:66,
                 from ..\..\include/wx/unichar.h:15,
                 from ..\..\include/wx/strvararg.h:22,
                 from ..\..\include/wx/string.h:46,
                 from ../../src/common/file.cpp:105:
C:/Apps32/TDM-GCC5_1x-32/include/pthread.h:227:8: error: redefinition of 'struct
 timespec'
 struct timespec {
        ^
In file included from C:/Apps32/TDM-GCC5_1x-32/include/unistd.h:95:0,
                 from ../../src/common/file.cpp:54:
C:/Apps32/TDM-GCC5_1x-32/include/parts/time.h:65:8: error: previous definition o
f 'struct timespec'
 struct timespec
        ^
makefile.gcc:6494: recipe for target 'gcc_mswudll51Xsjlj\monodll_file.o' failed
mingw32-make: *** [gcc_mswudll51Xsjlj\monodll_file.o] Error 1

Tim S.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: stahta01 on June 29, 2015, 07:49:33 am
Simplest code that gives the error.

Code
#include <pthread.h>
#include <unistd.h>

int main()
{
    return 0;
}


Code
-------------- Build: Release in testgcc51x (compiler: gcc-5.1.x)---------------

mingw32-g++.exe -Wall  -c C:\SourceCode\Test\testgcc51x\main.cpp -o obj\Release\main.o
In file included from C:/Apps32/TDM-GCC5_1x-32/include/unistd.h:95:0,
                 from C:\SourceCode\Test\testgcc51x\main.cpp:2:
C:/Apps32/TDM-GCC5_1x-32/include/parts/time.h:65:8: error: redefinition of 'struct timespec'
 struct timespec
        ^
In file included from C:\SourceCode\Test\testgcc51x\main.cpp:1:0:
C:/Apps32/TDM-GCC5_1x-32/include/pthread.h:227:8: error: previous definition of 'struct timespec'
 struct timespec {
        ^

Tim S.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: scarphin on June 29, 2015, 11:54:31 am
tdm-gcc is somehow less vulnerable to that bug, I suspect tdragon has already fixed that in his own builds (way before 5.1) or am I wrong?

It was NOT fixed in his 4.8 GCC based release. I do NOT remember if I tested the 4.9 based release for the bug or not.

Tim S.
I haven't checked the code (I even didn't know where to check before ollydbg spotted it). I am just judging by the fact that tdm-4.9.2 (iirc also tdm-4.8.1) can compile wx2.8 in 64-bit bitness. It might be another factor though.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: ollydbg on June 29, 2015, 04:21:56 pm
I hadn't seen that PCH patch before; so, it's not present in the 5.1.0 release.
Hi, John, I thought you could see it, because I post some messages in mingw-w64 maillist, see: [Mingw-w64-public] can anyone supply a debug version of cc1plus.exe? (https://sourceforge.net/p/mingw-w64/mailman/message/34137144/) about one month ago.

The real bug report are in GCC bugzilla, see: 56926 – Crash (without ICE) while compiling Boost.Math (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926), especially my Comment 17 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926#c17), in my comment, I see that the crash can be simply fixed by set a large value of "pch_VA_max_size". About two or three days ago, I see another person post a patch GCC bug 14940 Comment 47 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c47), he said this patch should work better than my change. I don't have ability to build GCC myself, so I can't confirm whether his patch works better. His comments are mainly in MinGW-w64 - for 32 and 64 bit Windows / Bugs / #382 PCH: cc1plus.exe crash on Windows8.1 (https://sourceforge.net/p/mingw-w64/bugs/382/), see omgwtfbbq (https://sourceforge.net/u/xricht17/)'s comments in that Bug report.

Currently, PCH is disabled when building C::B with wx3.x under Windows, because of this crash issue. I hope next release of TDM gcc can solve this issue, thanks.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: TDragon on June 29, 2015, 06:24:57 pm
Some reason two different defines of the struct timespec was seen.

Aha, the newer mingwrt-3.21 added a struct timespec definition that wasn't present in 3.20-2.

I think the correct place to fix this will be in winpthreads; now testing a patch. In the meantime I'm reverting to mingwrt-3.20 in the installer and as the recommended version as it didn't have this problem.

-John E. / TDM
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: rresto on July 01, 2015, 10:53:06 pm
Hi, if I try to debug a simple C hello program, it's OK with Tdm 4.9 64 bit, but not OK with Tdm 5 64 bit (error displayed at gdb.exe startup : code 0xc000007b).

In 32 bits its OK
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: TDragon on July 02, 2015, 01:59:39 am
Did you add the (tdm-gcc)/gdb32/bin or (tdm-gcc)/gdb64/bin directories to your PATH? (You shouldn't do this.)

If not, is there a 32-bit python27.dll present somewhere else?

EDIT: Found that the 32-bit Python was mistakenly put in the 64-bit TDM GDB package, and another 64-bit Python on my system was masking the problem. A new package has been uploaded.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: headkase on July 02, 2015, 09:22:32 pm
No matter what I do I cannot get wxMSW 2.8.12 to compile with TDM 64 5.1.0.  It compiles with TDM 32 5.1.0.  Much googling has pointed to the MinGW-W64 runtime API as being the culprit but I have no idea how to go about fixing that.  Can you give any tips or a specific configuration to use?  I need 2.8.12 for Code::Blocks itself when building that.  I have successfully built wxWidgets 3.0.2 with TDM 64 5.1.0 but the resulting Code::Blocks editor with that has an issue with the caret (cursor) when navigating source files.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: scarphin on July 02, 2015, 11:45:08 pm
headkase: tdm4.9.2 successfully compiles wx2.8.12 (at least with a 64-bit friendly patch to the wx2.8 part) but be aware there is a bug in wx2.8 that effects debugger's frame numbers and stack switching.
Details here -> http://forums.codeblocks.org/index.php/topic,20155.0.html (http://forums.codeblocks.org/index.php/topic,20155.0.html)
If you want to go that way I've posted a patch to fix this in the above thread and it works but it is not applied to CB and won't be.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: TDragon on July 03, 2015, 02:31:48 am
I've successfully built under TDM64 with -m32, generating 32-bit code - but if you're talking about 64-bit wxWidgets and 64-bit Code::Blocks, I've never yet tried because I don't think it's fully supported yet on the Code::Blocks side.

-John E. / TDM
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: headkase on July 03, 2015, 03:17:51 pm
Yes, TDragon, I am talking about building a 64 bit wxMSW 2.8.12 and 64 bit Code::Blocks on Windows.  wxMSW 2.8.12 compiles and works fine with TDM 5.1.0-3 32 bit so if 64 bit just isn't possible with wxMSW then I'll keep the 32 bit compiler installed and just use that for Code::Blocks SVN builds while using the 64 bit compiler for my personal projects.

As already said, wxWidgets 3.0.2 64 bit builds fine (with -fpermissive and -std=gnu++11 switches) with TDM64 5.1.0-2 and so does Code::Blocks SVN with it.  However, the text editor in the resulting binaries has issues with the caret/cursor not properly updating.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: headkase on July 03, 2015, 05:43:46 pm
headkase: tdm4.9.2 successfully compiles wx2.8.12 (at least with a 64-bit friendly patch to the wx2.8 part) but be aware there is a bug in wx2.8 that effects debugger's frame numbers and stack switching.
Details here -> http://forums.codeblocks.org/index.php/topic,20155.0.html (http://forums.codeblocks.org/index.php/topic,20155.0.html)
If you want to go that way I've posted a patch to fix this in the above thread and it works but it is not applied to CB and won't be.

Thank you for the advice scarphin.  Looks like I'll be sticking with 32 bit builds for the foreseeable future.  One thing I am interested about though: where did you get that dark theme for Code::Blocks?  I'd like that very much..  I'm Windows 8.1 64 bit if it matters. :)
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: scarphin on July 03, 2015, 07:01:50 pm
It's not a theme for CB, it's a win7 theme called Concave7. I just personalized the syntax highlighting and other colors. Colors other than the ones for the editor are not customizable without a general windows theme afaik.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: headkase on July 03, 2015, 07:52:01 pm
Ok, right on, thank you again scarphin.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: gd_on on July 06, 2015, 07:37:15 pm
I have found that using also -Wno-deprecated-declarations in the CXXFLAGS to compile wxWidgets 3.0.2 seriously diminishes the number of displayed warning when using TDM 5.1.0.
More, if you add this in the compiler options when compiling C::B with wxWidgets 3.0.2 and TDM 5.1.0, you avoid tons of warnings (in fact always the same ones but displayed so many times !)

gd-on
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: ollydbg on July 10, 2015, 12:33:13 am
Hi, John, you may need the two patches to fix the pch issue, see:
Comment 49 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c49) and Comment 50 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c50).
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: Max on July 16, 2015, 11:25:48 pm
Hi,

Is there any reason not to have the sanitizer libraries in TDM-GCC 5.1? I can't use the sanitizer switches because the related libraries are missed!

Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: gd_on on July 17, 2015, 07:35:26 pm
Hi John,
I have a problem with TDM 5.1.0 gfortran. It happens with 32 bits version (in C:\MinGW32 for me) and 64 bits version (in C:\MinGW64 for me).
There are no such problem with TDM 4.9.2 gfortran.
I have put a small test case in a 7z file. It opens a file and read 1 line.
The program crashes when it reaches the open instruction.
In release mode I obtain this message in the console :
Program receive signal SIGSEGV : Segmentation fault ...
In debug mode, I obtain a message in Call stack view (see the .jpg screen capture).
A little bit different with 64 bit compiler, but same problem.

As told, no such problem with 4.9.2 TDM versions.
What could be wrong ?

Same problem on 3 different PC, all running Windows 7 (pro or family edition)

gd_on
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: ouch on July 31, 2015, 12:03:36 am
I've been trying to update my compiler to the new 5.1 but I keep getting a crash when codeblocks is loading it's GUI (I get the splash screen and it seems to load the plugins but crashes when it goes to load the gui.)

Here is the rpt file it creates:

Code
Error occured on Wednesday, July 29, 2015 at 17:53:53.

codeblocks.exe caused an Access Violation at location 62CC8871 in module wxmsw28u_gcc_custom.dll Reading from location 00000010.

Registers:
eax=02902318 ebx=02902318 ecx=00000000 edx=00000000 esi=62e3eac8 edi=62e1a5a0
eip=62cc8871 esp=0028f070 ebp=0028f118 iopl=0         nv up ei pl zr na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246

AddrPC   Params
62CC8871 029DDD50 0028F1B4 0028F1B8  wxmsw28u_gcc_custom.dll!wxCheckDynamicCast(wxObject*, wxClassInfo*)
62B33EFA 02758380 02902318 00000000  wxmsw28u_gcc_custom.dll!wxXmlResourceHandler::CreateResource(wxXmlNode*, wxObject*, wxObject*)
62B38390 02758380 02902318 00000000  wxmsw28u_gcc_custom.dll!wxXmlResource::CreateResFromNode(wxXmlNode*, wxObject*, wxObject*, wxXmlResourceHandler*)
62B3935E 02902318 00000000 0028F370  wxmsw28u_gcc_custom.dll!wxXmlResourceHandler::CreateChildren(wxObject*, bool)
62B08A89 029DDD50 0028F424 0028F428  wxmsw28u_gcc_custom.dll!wxPanelXmlHandler::DoCreateResource()
62B33EFA 02756AA8 028A2CE8 02902318  wxmsw28u_gcc_custom.dll!wxXmlResourceHandler::CreateResource(wxXmlNode*, wxObject*, wxObject*)
62B38390 02756AA8 028A2CE8 02902318  wxmsw28u_gcc_custom.dll!wxXmlResource::CreateResFromNode(wxXmlNode*, wxObject*, wxObject*, wxXmlResourceHandler*)
62B38BB6 02902318 028A2CE8 0028F5D4  wxmsw28u_gcc_custom.dll!wxXmlResource::LoadPanel(wxPanel*, wxWindow*, wxString const&)
00434789 028A2CE8 00000000 FFFFFFFF  codeblocks.exe!0x34789
0041C6A5 61851A5F 0028F730 0223FAEC  codeblocks.exe!0x1c6a5
6184F6B8 027441D8 00000000 00000180  codeblocks.dll!ZN15DebuggerManager13CreateWindowsEv
0047224D 028A95A8 0028F934 FFFFFFFF  codeblocks.exe!0x7224d
00486312 0028FA6C 00000001 FFFFFFFF  codeblocks.exe!0x86312
0048E624 00000000 0028FCCC 007052F8  codeblocks.exe!0x8e624
0040208D 00000000 FFFFFFFF 00000000  codeblocks.exe!0x208d
00407E6F 0028FDCC 006D6190 007A0000  codeblocks.exe!0x7e6f
62757E6D 00400000 00000000 009D2756  wxmsw28u_gcc_custom.dll!wxEntryReal(int&, wchar_t**)
00401DA8 7EFDE000 00000000 7EFDE000  codeblocks.exe!0x1da8
004010FD 7EFDE000 771919C1 00000000  codeblocks.exe!0x10fd
77C292E2 004012A0 7EFDE000 00000000  ntdll.dll!__RtlUserThreadStart
77C292B5 004012A0 7EFDE000 00000000  ntdll.dll!_RtlUserThreadStart

codeblocks.exe   13.12.0.0
ntdll.dll      6.1.7601.18869
kernel32.dll   6.1.7601.18869
KERNELBASE.dll   6.1.7601.18869
wxmsw28u_gcc_custom.dll   2.8.12.0
ADVAPI32.DLL   6.1.7601.18869
msvcrt.dll     7.0.7601.17744
sechost.dll    6.1.7601.18869
RPCRT4.dll     6.1.7601.18912
SspiCli.dll    6.1.7601.18912
CRYPTBASE.dll   6.1.7601.18912
COMCTL32.DLL   6.10.7601.18837
GDI32.dll      6.1.7601.18898
USER32.dll     6.1.7601.17514
LPK.dll        6.1.7601.18923
USP10.dll      1.626.7601.18454
SHLWAPI.dll    6.1.7601.17514
COMDLG32.DLL   6.1.7601.17514
SHELL32.dll    6.1.7601.18762
OLE32.dll      6.1.7601.18915
OLEAUT32.DLL   6.1.7601.18679
WINMM.DLL      6.1.7601.17514
WINSPOOL.DRV   6.1.7601.17514
WSOCK32.DLL    6.1.7600.16385
WS2_32.dll     6.1.7601.17514
NSI.dll        6.1.7600.16385
SHFOLDER.DLL   6.1.7600.16385
exchndl.dll    0.7.5.0
mgwhelp.dll    0.7.5.0
dbghelp.dll    6.3.9600.17029
PSAPI.DLL      6.1.7600.16385
VERSION.dll    6.1.7600.16385
codeblocks.dll
wxpropgrid.dll
IMM32.DLL      6.1.7601.17514
MSCTF.dll      6.1.7601.18731
avghookx.dll   15.0.0.6081
uxtheme.dll    6.1.7600.16385
dwmapi.dll     6.1.7600.16385
CRYPTSP.dll    6.1.7601.18741
rsaenh.dll     6.1.7600.16385
RpcRtRemote.dll   6.1.7601.17514
msftedit.DLL   5.41.21.2510

Windows 6.1.7601
DrMingw 0.7.5
Using win 7 64bit, tdm mingw 5.1, wxWidgets 2.8: git says: v2.8.12-132-g1ff8161 The version of codeblocks is SVN 10376

The commands I have been using to build wxWidgets are as follows:

mingw32-make -j7 -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 CFLAGS=-O3 CXXFLAGS="-O3 -fno-keep-inline-dllexport" BUILD=release clean
mingw32-make -j7 -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 CFLAGS=-O3 CXXFLAGS="-O3 -fno-keep-inline-dllexport" BUILD=release

And when I remove the -O3 optimization it all works fine so it looks like a compiler issue.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: reckless on August 01, 2015, 03:05:54 pm
-O3 optimization has shown to cause problems in past versions as well, i believe thats why the -O2 level is default.
the sanitizer libraries dont build on 64 bit mingw yet, the 32 bit mingw64 sanitizer libraries do build with some patching but if they work i dont know.

The 5.1.0 gcc release had some nasty bugs on windows that needed patching atleast if you wanted to use the dwarf debugging format instead of the slow as molasses setjump/longjump debugging format, 5.2.0 has the same bugs but fixes some of the other things that needed patching as well as fixing openmp.

Im collecting the new patches needed for 5.2.0 and will post them to TDM soon, might be worth waiting for the next release :)
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: stahta01 on September 21, 2015, 02:31:05 am
I found out that I can avoid building wxWidgets 3.0.2 with CXXFLAGS="-std=gnu++11" if I instead define "-DHAVE_TR1_TYPE_TRAITS" with the MSys2 MinGW64 compiler; I have NOT had time to confirm it works with TDM's Compilers.

Tim S.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: ollydbg on September 27, 2015, 08:09:42 am
I found out that I can avoid building wxWidgets 3.0.2 with CXXFLAGS="-std=gnu++11" if I instead define "-DHAVE_TR1_TYPE_TRAITS" with the MSys2 MinGW64 compiler; I have NOT had time to confirm it works with TDM's Compilers.

Tim S.

Hi, Tim, I think this postRe: Build C::B against wx3.02 with gcc 5.2 under Windows (http://forums.codeblocks.org/index.php/topic,20607.msg140165.html#msg140165) mentions the correct fix about this issue, with this patch, I'm building wx3 without c++/g++11 mode.

Also, I see a lot of warnings when building wx3 about -Wdeprecated-declarations, so as gd_on mentioned in this post:
Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28) (http://forums.codeblocks.org/index.php/topic,20382.msg138860.html#msg138860)
We may need an option: add -Wno-deprecated-declarations in the CXXFLAGS to suppress such warnings.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: MortenMacFly on October 03, 2015, 01:03:32 pm
Has anyone tried to use the GDB (32 bit) that ships with this compiler to debug C::B on Windows?
It fails for me all the time with this error:
[debug]C:/crossdev/src/gdb-7.9.1/gdb/buildsym.c:1023: internal-error: prepare_for_building: Assertion `current_subfile == NULL' failed.
[debug]A problem internal to GDB has been detected,
[debug]further debugging may prove unreliable.
[debug]This is a bug, please report it.  For instructions, see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]This application has requested the Runtime to terminate it in an unusual way.
[debug]Please contact the application's support team for more information.

...an obviously the debugger is gone then.
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: oBFusCATed on April 03, 2016, 07:10:43 pm
@Morten: I can use the debugger to debug codeblocks, but it is not very stable. For example "thread apply all bt" crashed gdb.

@TDragon: Can you tell me why gdb32.exe is starting another version of gdb32.exe? It seems this is TDM specific, because my old version of MinGW doesn't do it (7.6.1).
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: thomas on April 19, 2016, 06:31:05 pm
I just found that this particular compiler adds 123 to 124 kilobytes of code for operator new on trivial types, any idea how and why?

The verdict is this:

I started writing a parser, and relatively early (when the compiled code size was around 10kB) I added a std::vector in some place. Nothing fancy, and 3-4 harmless lines of code. Bang. Executable size jumped well above 134kB. I noticed by accident because Code::Blocks displays the size in the log pane.

Not like 134kB is a forbiding size on a modern computer, but... wow, dude, std::vector seems to be quite a fat pig, seeing how it's supposed to be kinda slim wrapper around an array with some rather simple resizing logic. Probably a lot of debug symbols and stuff... hmm... no, already building without symbols, optimizing, and stripping. Huh. It's not symbols, then it must be RTTI and exceptions. The code doesn't use these, but std::vector throws, so that's probably it. Building with exceptions and RTTI disabled. Same thing.

If I comment out the single push_back, code size drops back to 10kB. What the hell is push_back doing that's so complicated?

Well, it seems std::vector just sucks, so I'll just write my own implementation, and one that doesn't need to be 100% standards compliant, too (so I can cut a few corners). Fast forward one day. Well, it works fine, but it's exactly the same code size, WTF? Dude, WTF? I know that my code doesn't do anything that justifies this bloat. How is this possible?

Commenting out line by line to find the culprit. When commenting out the new expression inside the reallocation function, code size suddenly drops to 9.5kB.

Uh huh. So... let's try something different. Ignoring the correctness issues of leaking and returning an undefined value, let's check the difference between these three:

int main() { }
int main() { return *(int*)malloc(4); }
int main() { return *new int; }


9kB / 9kB / 134kB. How is that possible? Trying Clang/LLVM 3.7: 15.5kB / 15.5kB / 15.5kB. Trying MinGW-w64 (the 5.1 and 5.2 versions available from the MinGW-w64 site): 9kB / 9kB / 9kB.

Running objdump -dSC and diffing the outputs unsurprisingly shows generally similar code at the beginning (with different addresses in JMP/CALL, but otherwise identical) followed by loads of extra code. It's most definitively not symbols or something the like.

Any idea what I'm doing wrong?
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: ouch on May 24, 2016, 09:57:53 pm
Does anyone know if TDM mingw is officially abandoned? It's been nearly a year since the last release.

I switched to mingw w64 5.3 and found all the bugs TDM mingw 5.1 had are gone. wxWidgets 2.8 doesn't seem to compile with it. (3.1 works fine though)

So I'm in a bit of mingw limbo where none of the new releases will completely work for me...
Title: Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
Post by: herbthom on May 24, 2016, 10:35:39 pm
Any idea what I'm doing wrong?

Are you dynamically linking libstdc++ or accepting the default to statically link?

I get 16,896 bytes with:
c++ new.cpp -s -shared-libstdc++