GCC 4.4.1-tdm-2 for MinGW (with installer)

[TDragon]

The second TDM-GCC release of GCC 4.4.1 is now available!

NOTICE:
The first TDM-GCC release of GCC 4.4.1 had a bug that caused a major slowdown in nearly any non-trivial program that it compiled. Be sure to upgrade to the new TDM-2 release if you're currently using 4.4.1-tdm-1.

See the original post for changes in the vanilla 4.4 series sources as well as TDM-GCC specific bug fixes.

I tested this release by successfully building wxWidgets (2.8.10), and building and running Code::Blocks (SVN r5848), both without errors!

Binary packages are available for the Ada, C, C++, Fortran, Objective-C, and Objective-C++ languages, as drop-in replacements for the MinGW project's official gcc packages. Additionally, the TDM/MinGW installer will automatically install TDM-GCC and the MinGW compiler suite for you. Full details and download links are at http://www.tdragon.net/recentgcc/ .

Disclaimer:
The TDM-GCC builds are unofficial replacements for the official MinGW releases of GCC binaries. TDM-GCC was previously recommended for experimentation purposes only, but constant use in day-to-day development and a total download count of over 60,000 have proven the TDM-GCC releases to be at least as usable as the most recent official MinGW GCC release. (Please note that this does not mean that there are no bugs; merely that there is a different set of bugs with a similar or lesser average criticality.) Therefore, TDM-GCC is now heartily endorsed for production use in any non-critical environment, with only the following caveats:

• TDM-GCC is not formally affiliated with or endorsed by the MinGW project (although several MinGW team members make use of it)
• No level of support for TDM-GCC is in any way guaranteed (although a best effort is made to fix bugs as they are found or forward them to GCC Bugzilla)

Cheers,
John E. / TDM

[killerbot]

as always John : superb and many thanks !!!

Do you any idea, when your super package will contain GDB 7.0 ?

Not that we need it, since we already upgraded manually ;-)

[ollydbg]

as always John : superb and many thanks !!!

Do you any idea, when your super package will contain GDB 7.0 ?

Not that we need it, since we already upgraded manually ;-)

TDM-GCC is great!!!

Yes, I suggest GDB 7.0 should be include in this package.

Thanks.

[bhishmar]

Hi all
First let me record my sincere thanks & appreciation to John /TDragon, for bring out such an excellent & usefull product.

A suggestion: The last update date on the first post must come at the top of the first post.
New users like me are getting confused that, the cpu/slowdown bug is being  reported even after tmd-1 to tdm-2 release, by some posters below. It took some time to findout they were referring to the earlier release.

Thanks & regards.

[killerbot]

  any 4.4.2 in the pipeline ? 

[Conan Kudo]

How about an MinGW-w64 version? Is that in the pipeline?

[TDragon]

killerbot: yes.

Pharaoh Atem: maybe.

[nenin]

I found a problem with 4.4.1-tdm-2, regarded to the optimization. I observe a lost of precision in numeric code if "O" flags are used. In case of O1 it is small, but not negligible, in case of O2 it is intolerable.
I found that errors occurs when "O" flags are used, from "O1". If the the same set of the command-line optimization options introduced separately as it described in GCC manual, no problem detected up to "-fexpensive-optimizations".

[TDragon]

Have you observed similar problems in the official MinGW release(s)?

[nenin]

Have you observed similar problems in the official MinGW release(s)?

I not tried official release. Looks like problem not exists in 4.4.0-tdm. At least I do not found it, but I used it a lot.

[nenin]

Have you observed similar problems in the official MinGW release(s)?

So, bad news. I reproduced problem on official MinGW 4.4.0, on 4.4.0-tdm-1-dw2 and on 4.4.1-tdm-2-dw2.
4.3.1-tdm-1-dw2  and 4.3.3-tdm-1-dw2 works properly. Usage of the "-O1"... "-O3" with  4.4.* leads to generation fallacious code  while the application of the full set of stand-alone  switches like "-fauto-inc-dec -fcprop-registers -fdce -fdefer-pop -fdse -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-small-functions -fipa-pure-const -fipa-reference -fmerge-constants -fsplit-wide-types -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copyrename -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize -fthread-jumps -falign-functions -falign-jumps -falign-loops -falign-labels -fcaller-saves -fcrossjumping -fcse-follow-jumps -fcse-kip-blocks -fdelete-null-pointer-checks -fgcse -fgcse-lm -findirect-inlining -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec -fschedule-insns -fschedule-insns2 -fstrict-aliasing -fstrict-overflow -ftree-switch-conversion -ftree-pre -ftree-vrp -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-sra -ftree-ter -funit-at-a-time" does not.

[Max]

nenin,

I observed that problem in several occasions. Using official MinGW and TDM as well. In most of the cases the prolem was not in compiler but in the source code. Writing floating point code is not trivial. Especially if you are playing with precions and using 386 processor family (80 bit FPU register). Try the options

-O2  -mfpmath=sse -msse2

if the problem disappears review your code. Anyway we are OT, not related to CB.

Max

[nenin]

nenin,
<***>
if the problem disappears review your code.
Max

Could you please read more carefully what I wrote?  :roll:

[jaxon]

Have you observed similar problems in the official MinGW release(s)?

So, bad news. I reproduced problem on official MinGW 4.4.0, on 4.4.0-tdm-1-dw2 and on 4.4.1-tdm-2-dw2.

It's very interesting what about Linux version of gcc...

[Max]

Nenin wrote,,
>Could you please read more carefully what I wrote?

Yes I did. Unfortunately (please don't get me wrong) statements like

>...leads to generation fallacious code
>...I observe a lost of precision in numeric code if "O" flags are used.

really mean nothing :-)

You should post a small testcase to be analyzed. The only thing I get is that you have problems with "precision" (how much? which one? what?). Because using finite precision the results depend on the order of instructions (and optimizer is reordering/deleting instruction) I suggested (at least) to try using IEEE754.

Post, not here, a small testcase (for example try to report the observed issue in the bug archive in the TDM site).


Bye

Max