Author Topic: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)  (Read 54803 times)

Offline gd_on

  • Regular
  • ***
  • Posts: 495
Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
« Reply #30 on: October 07, 2013, 07:31:06 pm »
Thanks John.
I have seen this on your web site this morning but I have only been able to try it this evening, at home, where I had the problem.
It looks OK. H: is reactivated and do not interfere.
Thanks again. ;)

gd_on
Windows 10, svn C::B (last version or almost!), WxWidgets 3.1.3, Compilers 8.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\MinGW64) or 32 bits (sjlj, posix in C:\MinGW32).

Offline ptDev

  • Almost regular
  • **
  • Posts: 222
Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
« Reply #31 on: October 07, 2013, 10:58:11 pm »
Thank you so much for all your hard work!
Please forgive my impatience, as I even felt the need to PM you in anticipation... :)

Online stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #32 on: October 08, 2013, 08:11:55 pm »
unfortunately I didn't figure out a good test case for reproduction.
OK, I found a way to reproduce:
For me, it happens when I compile a simple file like configmanager-revision.cpp
What you need to do:
- compile wx 2.9.5 with GCC 4.8.1
- start compiling C::B with the related C::B "-wx29" project -> this will create the PCH file
- when it crashes, run at the command prompt:
- g++.exe -DwxUSE_WX_RESOURCES=0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs29\include -c sdk\configmanager-revision.cpp
--> It will crash for me. Removing ANY of the remaining option will make it work but also changes the handling of the PCH file.
So it really seems related to the handling of PCH file (and yes, I've completely cleaned everything in the first place, so the PCH file is generated with GCC 4.8.1, too).

Any idea of what going on here? Note that PCH works just fine for the older wx 2.8.12... ?!

Finally had time; it fails Compiling of PCH against wxWidgets trunk.
Disabled PCH and it is working be a while before it finishes building CB.

Googling implies cc1plus.exe might be crashing because of too small a stack size. 91M pch does not crash it; but, the wxWidget trunk results in about 140MB pch.

Possible related bug post: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
Possible related bug post: http://sourceforge.net/mailarchive/message.php?msg_id=30821409

PCH of this size works 128 MB (134,393,772 bytes). I got this size by un-defining WX_PRECOMP and commenting out "#include <wx/wxprec.h>" in sdk_common.h. So, it might be a header included by wxprec.h that is causing the crash.

Tim S.
« Last Edit: October 09, 2013, 12:35:05 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Online stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #33 on: October 09, 2013, 04:08:25 pm »
unfortunately I didn't figure out a good test case for reproduction.
OK, I found a way to reproduce:
For me, it happens when I compile a simple file like configmanager-revision.cpp
What you need to do:
- compile wx 2.9.5 with GCC 4.8.1
- start compiling C::B with the related C::B "-wx29" project -> this will create the PCH file
- when it crashes, run at the command prompt:
- g++.exe -DwxUSE_WX_RESOURCES=0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs29\include -c sdk\configmanager-revision.cpp
--> It will crash for me. Removing ANY of the remaining option will make it work but also changes the handling of the PCH file.
So it really seems related to the handling of PCH file (and yes, I've completely cleaned everything in the first place, so the PCH file is generated with GCC 4.8.1, too).

Any idea of what going on here? Note that PCH works just fine for the older wx 2.8.12... ?!


Found what I believe to be the real cause of crashing "wx/wxprec.h" was included inside the CB Header xtra_res.h.

I have not yet confirmed this a the cause; I have to cleanup my CB source file first.
Cleanup my CB source and the results do NOT confirm the issue to be fixed by removing the include of "wx/wxprec.h".

I have given up once more; it appears almost to be a un-guarded or circular header inclusion issue.

If I include both xtra_res.h and wx/msw/wrapcctl.h along with several other headers it had an issue; but, it seems to be hard to narrow it down completely.

Tim S.
« Last Edit: October 12, 2013, 03:18:57 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
« Reply #34 on: October 10, 2013, 02:38:17 am »
Also this post:
http://sourceforge.net/p/mingwbuilds/mailman/message/29214215/
It looks like GCC can not handle big PCH file correctly, but no one has debugged this issue. As in the message:http://sourceforge.net/mailarchive/message.php?msg_id=30821409

Kai said:
Quote
Well, this crash can have at least two different causes.  First would
be that precompiled headers are generated by different gcc-versions.
Second would be that precompiled-header-file exceeds in total 512 MB
size.

For both cases there is no real fix available for mingw-targets.

Regards,
Kai
Also, for QT, they have disabled PCH on MinGW GCC target: see:
https://codereview.qt-project.org/#change,34049
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
« Reply #35 on: October 10, 2013, 01:14:03 pm »
Now you only need to explain to me why your binaries are smaller.  ;D

Seriously, I switched to using MinGW-builds some months ago because Evil John wouldn't do a gcc-4.8 build, and building gcc is still something I'm not able to do successfully. I've had the impression that gcc-4.8 produces somewhat bigger executables than gcc-4.7. But alas, that's a possibility. Different compiler versions, different sizes.

Now I'm recompiling things built with the MinGW-builds 4.8.1 compiler using the TDM 4.8.1 compiler, same flags, same everything, and 731 kB becomes 710 kB.
« Last Edit: October 10, 2013, 01:15:36 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline TDragon

  • Lives here!
  • ****
  • Posts: 936
    • Twilight Dragon Media
Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
« Reply #36 on: October 10, 2013, 06:17:23 pm »
I think you mean Lazy John. :)

At any rate that is certainly an unexpected bonus. I expected all TDM-GCC-compiled binaries to be larger due to statically linking winpthreads into every binary, but I've noticed the same phenomenon -- many binaries are actually smaller with this release.

-John E. / TDM
http://tdm-gcc.tdragon.net/ - TDM-GCC compiler suite for Windows (GCC 5.1.0 2015-06-28, 32/64-bit, no extra DLLs)

Online stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #37 on: October 14, 2013, 03:36:39 pm »
unfortunately I didn't figure out a good test case for reproduction.
OK, I found a way to reproduce:
For me, it happens when I compile a simple file like configmanager-revision.cpp
What you need to do:
- compile wx 2.9.5 with GCC 4.8.1
- start compiling C::B with the related C::B "-wx29" project -> this will create the PCH file
- when it crashes, run at the command prompt:
- g++.exe -DwxUSE_WX_RESOURCES=0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -iquote.objs29\include -c sdk\configmanager-revision.cpp
--> It will crash for me. Removing ANY of the remaining option will make it work but also changes the handling of the PCH file.
So it really seems related to the handling of PCH file (and yes, I've completely cleaned everything in the first place, so the PCH file is generated with GCC 4.8.1, too).

Any idea of what going on here? Note that PCH works just fine for the older wx 2.8.12... ?!

From CB thread http://forums.codeblocks.org/index.php/topic,18412.msg126028.html#msg126028

Quote
Testing wxWidgets trunk SVN 70513 to see if problem exists; Did NOT see problem.

Testing wxWidgets trunk SVN 70514 to see if problem exists; Did see the problem.

Likely cause is "include/wx/generic/choicdgg.h"
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
« Reply #38 on: October 14, 2013, 04:24:44 pm »
If cc1plus.exe has debug information in it, then I think when it crashed, we can at least get a call-stack under GDB. Otherwise, it is hard to find the cause and fix it.
« Last Edit: October 15, 2013, 02:48:17 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ToApolytoXaos

  • Guest
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #39 on: October 23, 2013, 04:33:50 pm »
To gd_on: I would just turn off the "-Wunused-local-typedefs" warning instead.

You way might be faster; but, that way is safer.

Tim S.

I built wx2.8.12 lib by the command
Code: [Select]
cd wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release CXXFLAGS="-fno-keep-inline-dllexport" >log.txt 2>&1
Then I got a log.txt file which have 111460 lines. (mostly of the lines are the warning messages like: ...warning: typedef 'wxDummyCheckInt' locally defined but not used [-Wunused-local-typedefs].....)
So, maybe, I need to use:
Code: [Select]
cd wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release CXXFLAGS="-fno-keep-inline-dllexport -Wno-unused-local-typedefs" >log.txt 2>&1
to reduce the warnings, right?
ollydbg, I have done this myself and many warning messages were logged in a file of mine, which reports far too many warning messages to list them here in a code tag ( I have tried, that's why I said "far too many"; I can't post it due to over excessive line usage lol).

Also, another serious issue is with existing wxMSW projects I have already created. I have tried to recompile them with the currently compiled files, and it seems there's an issue with .rc files:

Code: [Select]
||=== Build: Debug in wxCartridgeStockTaking (compiler: GNU GCC Compiler) ===|
C:\Users\stefanos\GENERAL\Projects\WXPROJ~1\WXCART~1\resource.rc|3|fatal error: wx/msw/wx.rc: No such file or directory|
||can't open icon file `wx/msw/std.ico': No such file or directory|
||preprocessing failed.|
||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

With tdm's gcc 4.7.1 (32-bit), I did not have such issue before. Anyone else had anything similar to this?

Offline grf

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
« Reply #40 on: January 29, 2014, 10:57:06 am »
Some TDM-specific changes since the last release:
  • TDM-GCC now uses POSIX-style threads in its runtime libraries by way of the MinGW-w64 "winpthreads" layer. This allows std::thread and other C++11 pthreads-based features to be used.
  • TDM-GCC's version of winpthreads is patched for fully static use, so you won't be distributing an additional pthreads DLL with your programs. The patch gives winpthreads the ability to share thread handles among DLLs and EXEs.
  • By popular request, the "-static-libstdc++" option is back. It doesn't do anything, because TDM-GCC uses a static libstdc++ by default and you have to use "-shared-libstdc++" to get the DLL version, but it doesn't cause a compile-time error anymore.
  • By dint of some upstream work and some TDM-GCC-specific hacking, the Ada language is finally available for the TDM64 edition (32-bit or 64-bit compilation).

Interesting changes. However, the new tdm-gcc 4.8.1 (32 Bit version) created for my wxWidgets project a binary, which consumes a lot more CPU power than the version before, which was compiled with tdm-gcc 4.7.1. It's a single threaded application and the profiler told me, that about 50% of the runtime was lost in the both functions _spin_lite_lock and _spin_lite_unlock...  :o
Unfortunately I have no idea where to look for the reason...

Offline TDragon

  • Lives here!
  • ****
  • Posts: 936
    • Twilight Dragon Media
Re: TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)
« Reply #41 on: February 01, 2014, 01:40:03 am »
Interesting report. Those functions are part of the winpthreads layer used to implement threading functions in libgcc and libstdc++.

Coincidentally, the spinlock portion of winpthreads has been rewritten since the TDM-GCC 4.8.1 release. We'll see if the next release exhibits any improvements.

-John E. / TDM
http://tdm-gcc.tdragon.net/ - TDM-GCC compiler suite for Windows (GCC 5.1.0 2015-06-28, 32/64-bit, no extra DLLs)

Online stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #42 on: February 01, 2014, 01:46:31 am »

Also, another serious issue is with existing wxMSW projects I have already created. I have tried to recompile them with the currently compiled files, and it seems there's an issue with .rc files:

Code: [Select]
||=== Build: Debug in wxCartridgeStockTaking (compiler: GNU GCC Compiler) ===|
C:\Users\stefanos\GENERAL\Projects\WXPROJ~1\WXCART~1\resource.rc|3|fatal error: wx/msw/wx.rc: No such file or directory|
||can't open icon file `wx/msw/std.ico': No such file or directory|
||preprocessing failed.|
||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

With tdm's gcc 4.7.1 (32-bit), I did not have such issue before. Anyone else had anything similar to this?

That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

ToApolytoXaos

  • Guest
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #43 on: February 01, 2014, 09:50:14 am »
That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.

Hey Tim S., thanks for the reply. I have discovered the issue a long time ago and thought it was my problem, but seems it does it occasionally without any "warning" or whatsoever.

I have had created projects in the past with wxMSW-2.8.10, set my global variable names in Build options... > Search directories with standard C::B naming, like $(#wx.include) and so forth, and for some reason it would replace the variables with full expanded path; for example, C:\wxMSW-2.8.10\include etc etc.

That is why it would fail to build them with wxMSW-2.8.12, because the path it would look for, it would not exist anymore as I have removed it in favor of wxMSW-2.8.12.

Yes, I saved the project to accept any changes; besides, it would not let me close the project without accepting or discarding any project changes upon exit. It does not do this every time though; it happens from time to time, only on Windows of course.
« Last Edit: February 01, 2014, 09:57:35 am by ToApolytoXaos »

Online stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
Re: TDM-GCC 4.8 series (Latest: 4.8.1 - 2013-09-28)
« Reply #44 on: February 01, 2014, 03:30:26 pm »
That "wx/msw/wx.rc" message is 90% of the time because of a bad/missing CB search path.
Remember this is the search path for the "resource compiler" not the linker or normal compiler.

Tim S.

Hey Tim S., thanks for the reply. I have discovered the issue a long time ago and thought it was my problem, but seems it does it occasionally without any "warning" or whatsoever.

I have had created projects in the past with wxMSW-2.8.10, set my global variable names in Build options... > Search directories with standard C::B naming, like $(#wx.include) and so forth, and for some reason it would replace the variables with full expanded path; for example, C:\wxMSW-2.8.10\include etc etc.

That is why it would fail to build them with wxMSW-2.8.12, because the path it would look for, it would not exist anymore as I have removed it in favor of wxMSW-2.8.12.

Yes, I saved the project to accept any changes; besides, it would not let me close the project without accepting or discarding any project changes upon exit. It does not do this every time though; it happens from time to time, only on Windows of course.

Are you positive you used "$(#wx.include)" instead of $(#wx)/include) or $(#wx)\include) because I never had it happen to me.
But, I use "$(#wx.include)" all the time.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org