Author Topic: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)  (Read 20252 times)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6666
    • My Best Post
Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
« Reply #30 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.
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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5235
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
« Reply #31 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 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)
We may need an option: add -Wno-deprecated-declarations in the CXXFLAGS to suppress such warnings.
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
« Reply #32 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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12081
    • Travis build status
Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
« Reply #33 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).
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
« Reply #34 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?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline ouch

  • Almost regular
  • **
  • Posts: 223
Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
« Reply #35 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...
« Last Edit: May 24, 2016, 10:24:46 pm by ouch »

herbthom

  • Guest
Re: TDM-GCC 5 series (Latest: 5.1.0 - 2015-06-28)
« Reply #36 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++