TDM-GCC 4.2.3 for MinGW

[TDragon]

With GCC 4.2.3 now released, I've created the usual TDM binary distribution for MinGW. As always, binary packages are available as drop-in replacements for the MinGW project's official gcc packages.

I haven't deviated from my standard build process in creating this release, so I don't expect any problems. I always test every release to ensure that it can successfully build the latest version of wxWidgets and Code::Blocks SVN -- however, I haven't yet done so for this release because the majority of my CPU is currently occupied in a different build process. As soon as that's finished, I'll finish testing and confirm that everything works as expected.
Update:
Yes, C::B SVN and wxWidgets work fine with this release.

Full details are at http://www.tdragon.net/recentgcc/ .

Disclaimer:
You should only use this build if you need the features or bugfixes done since GCC 4.2.1. If you don't need them or aren't sure, you should instead use the official MinGW GCC 4.2.1 Technology Preview, or (most preferably) the official MinGW GCC 3.4.5 stable release.

Cheers,
John E. / TDM

[stahta01]

I am getting an error compiling an sample from wxWidgets trunk.

I was able to compile the sample using MinGW's GCC 3.4.5 and 4.2.1

Here is the error.

Code Select Expand


-------------- Build: Win32 DLL Release in isosurf ---------------

windres.exe -i F:\SOURCE~1\Projects\WXWIDG~1\WXWIDG~1.X\samples\sample.rc -J rc -o gcc_mswudll\isosurf\samples\sample.res -O coff -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\lib\gcc_dll_multi_26\mswu -I.\..\..\..\include -I. -I.\..\..\..\samples -IC:\Apps\MinGW_GCC_tdm_423\include -IF:\SOURCE~1\Projects\WXWIDG~1\WXWIDG~1.X\samples -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x
g++.exe  -g -O2 -Wall -DWIN32 -D__WXMSW__ -D_UNICODE -DWXUSINGDLL -D_WINDOWS -DNOPCH  -fno-strict-aliasing   -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\lib\gcc_dll_multi_26\mswu -I.\..\..\..\include -I. -I.\..\..\..\samples -IC:\Apps\MinGW_GCC_tdm_423\include -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\samples\opengl\isosurf -IF:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x -c F:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\samples\opengl\isosurf\isosurf.cpp -o gcc_mswudll\isosurf\isosurf.o
In file included from c:/apps/mingw_gcc_tdm_423/bin/../lib/gcc/mingw32/4.2.3/../../../../include/c++/4.2.3/istream:845,
                 from c:/apps/mingw_gcc_tdm_423/bin/../lib/gcc/mingw32/4.2.3/../../../../include/c++/4.2.3/fstream:45,
                 from F:\SourceCode\Projects\wxWidgets\wxWidgets-2.9.x\samples\opengl\isosurf\isosurf.cpp:50:
c:/apps/mingw_gcc_tdm_423/bin/../lib/gcc/mingw32/4.2.3/../../../../include/c++/4.2.3/bits/istream.tcc:46:18: error: F:/SourceCode/Projects/wxWidgets/wxWidgets-2.9.x/locale: Permission denied
Process terminated with status 1 (0 minutes, 4 seconds)
1 errors, 0 warnings


[lemd]

Is it can be worked on Windows XP?

[TDragon]

Nope, Windows 3.1 only, sorry...

...Why wouldn't it work on XP? I can understand if you wanted to know whether it worked on Vista (it does).

[thomas]

By the way, TD... I tried your 4.3.0 build too, very much appreciated (because I'm too stupid to build myself, for some reason it never works).

Unluckily, it seems like the GCC team still has to do some serious overhauling on the optimizer before 4.3.0 becomes usable. I had it move code which wasn't invariant and which was marked __volatile__ out of a loop. To make matters worse, the exit condition depended on that code (resulting in an infinite loop). So basically, that makes 4.3.0 unusable.

[Ceniza]

I also tried your 4.3.0 release and it complains about CreateProcess not being found whenever I try to build a program. Mr. Thomas told me to rename it, but it didn't work. More or less like Mr. T, I'm too stupid to make it work.

[asdz]

With GCC 4.2.3 now released, I've created the usual TDM binary distribution for MinGW. As always, binary packages are available as drop-in replacements for the MinGW project's official gcc packages.

I haven't deviated from my standard build process in creating this release, so I don't expect any problems. I always test every release to ensure that it can successfully build the latest version of wxWidgets and Code::Blocks SVN -- however, I haven't yet done so for this release because the majority of my CPU is currently occupied in a different build process. As soon as that's finished, I'll finish testing and confirm that everything works as expected.
Update:
Yes, C::B SVN and wxWidgets work fine with this release.

Full details are at http://www.tdragon.net/recentgcc/ .

Disclaimer:

You should only use this build if you need the features or bugfixes done since GCC 4.2.1. If you don't need them or aren't sure, you should instead use the official MinGW GCC 4.2.1 Technology Preview, or (most preferably) the official MinGW GCC 3.4.5 stable release.

Cheers,
John E. / TDM

Why while compiling an OpenMP program with your GCC distribution... it seems to recognize only one core?
(The program that i tested works fine on Linux and used flag -fopenmp)

[TDragon]

thomas:

By the way, TD... I tried your 4.3.0 build too, very much appreciated (because I'm too stupid to build myself, for some reason it never works).

Yeah...let's just say that while the process is indeed as simple as "configure, make, install", when things go wrong it's confoundedly hard to figure out why. Apparently, buying your sacrificial chickens from the correct vendor plays an important role.

Unluckily, it seems like the GCC team still has to do some serious overhauling on the optimizer before 4.3.0 becomes usable. I had it move code which wasn't invariant and which was marked __volatile__ out of a loop. To make matters worse, the exit condition depended on that code (resulting in an infinite loop). So basically, that makes 4.3.0 unusable.

Wow. Thanks for pointing this out. I've finally finished porting the patchset from the official MinGW 4.2.1 release to the 4.3 series for a soon-to-be TDM release with shared libgcc&libstdc++ and DW2 unwinding; now it looks like it might be a good idea to apply it to another 4.2 release as well.

If you have the time and inclination to create one, I'd really appreciate a testcase of some sort which shows this happening; even if I can't fix it myself (and I probably can't), I can send it on as a GCC PR, or ping it harder if it's already been filed there. A bug report on the TDM-GCC SF tracker would be optimal.

Ceniza:

I also tried your 4.3.0 release and it complains about CreateProcess not being found whenever I try to build a program. Mr. Thomas told me to rename it, but it didn't work. More or less like Mr. T, I'm too stupid to make it work.

If you can post the output with -v added to the command line here or in a support request, I can try to troubleshoot for you and add pertinent info to the README so other people don't run into the same problem. Also, it may well be a bug.

asdz:

Why while compiling an OpenMP program with your GCC distribution... it seems to recognize only one core?
(The program that i tested works fine on Linux and used flag -fopenmp)

I only have a single-core CPU currently, so this one would be harder for me to troubleshoot. I recommend you try your program on the official MinGW GCC 4.2.1 release. If it works as you expect there but not in TDM-GCC, I can try comparing the two to see what changes to make.

A parting shot:
You may have noticed that I haven't posted my typical announcement here concerning the TDM 4.3.0 release. This is because 4.3.0 currently does not successfully build Code::Blocks. I have not yet looked into the source of the problem.

[Ceniza]

Thank you for your interest, but running it with -v gave me all the information I needed. It seems I'm more stupid than I expected...

When I installed your 4.3.0 version I just renamed the current bin directory of my 4.2.1-dw2 and decompressed 4.3.0 on the already existent MinGW directory (so I would have a quick way to go back to 4.2.1). Problem was I forgot to copy all of the binutils to the newly created bin directory. To sum it up, the error was that gcc couldn't find as.exe.

Now it compiles without complaining

So far the 'hello world' program works. I'm gonna try a few more

[edit]
The only 'problem' so far is that debug builds are twice the size of those compiled with 4.2.1.
[\edit]

[Biplab]

thomas:

By the way, TD... I tried your 4.3.0 build too, very much appreciated (because I'm too stupid to build myself, for some reason it never works).

Yeah...let's just say that while the process is indeed as simple as "configure, make, install", when things go wrong it's confoundedly hard to figure out why. Apparently, buying your sacrificial chickens from the correct vendor plays an important role.

I tried the same. But unfortunately the build process stopped with a fatal error. I was cross-compiling it in Fedora 8. The strange thing is I have compiled GCC-4.1.x and 4.2.x with this box without any problem.

Why while compiling an OpenMP program with your GCC distribution... it seems to recognize only one core?
(The program that i tested works fine on Linux and used flag -fopenmp)

Did you try specifying the number of threads before running your app?? On Windows, export the following environment variable as-

Code Select Expand

set OMP_NUM_THREADS=2
or in Linux,

Code Select Expand

export OMP_NUM_THREADS=2

You can also add the following code at the top of your main() function in your code to set the number of threads.

Code Select Expand

omp_set_num_threads(2);

Please note that the above code has higher precedence than the environment variables.

[asdz]

Did you try specifying the number of threads before running your app?? On Windows, export the following environment variable as-

Code Select Expand

set OMP_NUM_THREADS=2
or in Linux,

Code Select Expand

export OMP_NUM_THREADS=2

You can also add the following code at the top of your main() function in your code to set the number of threads.

Code Select Expand

omp_set_num_threads(2);

Please note that the above code has higher precedence than the environment variables.

When using set omp_num_threads=2... the program works PERFECT on both cores parallel....
But when using omp_get_num_procs() (this is the fuction that returns the physical number of cores) returns the number of threads i had set before... but on Visual Studio compiler this doesnt happen.

Let's say we have:

Code Select Expand

#include <omp.h>
#include <stdio.h>


int main () {
  int id;
  omp_set_num_threads(3);
#pragma omp parallel private(id)
  {
    id = omp_get_thread_num();
    printf("Threads i have set: %d\n", id );
    #pragma omp barrier
  }
  printf("Real cores %d\n", omp_get_num_procs());
  getchar();
  return 0;
}

On Visual Studio i have
Thread i have set: 0
Thread i have set: 1
Thread i have set: 2
Real cores 2 (thats correct i have an core 2 duo proc.)

On GCC:
Thread i have set: 0
Thread i have set: 1
Thread i have set: 2
Real cores 3

it seems that can't recognize at once the number of cores... even using omp_get_num_threads() returns 1 if i don't have set earlier the number of threads... but if i set the numbers of thread = 2, because i have a Core 2 duo system and works perfectly....
anything on that?

[patlecat]

A parting shot:
You may have noticed that I haven't posted my typical announcement here concerning the TDM 4.3.0 release. This is because 4.3.0 currently does not successfully build Code::Blocks. I have not yet looked into the source of the problem.

Okay but why you still have it classified as Recommended Download when in fact it is not usable at the moment? I'm, really thankful for your work in general but this upset me, because i spent a lot of time installing this new release and trying fruitlessly to get Qt 4.4 to build. :?

Question: Has anyone had experience with the new official mingw gcc4.3?

[joubertdj]

A parting shot:
You may have noticed that I haven't posted my typical announcement here concerning the TDM 4.3.0 release. This is because 4.3.0 currently does not successfully build Code::Blocks. I have not yet looked into the source of the problem.

Okay but why you still have it classified as Recommended Download when in fact it is not usable at the moment? I'm, really thankful for your work in general but this upset me, because i spent a lot of time installing this new release and trying fruitlessly to get Qt 4.4 to build. :?

Question: Has anyone had experience with the new official mingw gcc4.3?

Mmmmhhh ... die MinGW 4.3 is not "official" ... it is "alpha" ... hence ... unstable ... only for "tinkering" / "bug finding" issues ...

[patlecat]

I know that it's alpha, but what else can you say about it? Have u actually used it?

[thomas]

Okay but why you still have it classified as Recommended Download when in fact it is not usable at the moment? I'm, really thankful for your work in general but this upset me, because i spent a lot of time installing this new release and trying fruitlessly to get Qt 4.4 to build. :?
Question: Has anyone had experience with the new official mingw gcc4.3?

Well, maybe it's called "recommended" because TDragon offers like 200 different releases, and this one is the most recent one with the most bugfixes? Besides, why is it automatically "useless" only because it doesn't build Code::Blocks?
The same goes for QT - you're being fruitless building a huge beast like QT using a custom-built compiler from an experimental development branch with a couple of patches applied, so... uh... err... what am I missing there?