Compiling GCC 4.x.x on MinGW / MSYS Fails

I've been attempting for the last week or so to compile any of the GCC 4 series of compilers to run in MinGW 5.1.6 / MSYS 1.0.11 (automated installers both from Sourceforge.org) which ships with GCC version 3.4.5. The end goal is to get GCC 4.5 to install, but I haven't been able to get any of the 4.x.x compilers to build.

I've narrowed it down to a sequence of build instructions that result in some unusual behavior. The compiler executes:

build/genmodes.exe > tmp-modes.c
/bin/sh ../../gcc-4.2.4/gcc/../move-if-change tmp-modes.c insn-modes.c
echo timestamp > s-modes
gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-fno-common   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.2.4/gcc -I../../gcc-4.2.4/gcc/.
-I../../gcc-4.2.4/gcc/../include -I./../intl -I../../gcc-4.2.4/gcc/../libcpp/include
-I../../gcc-4.2.4/gcc/../开发者_StackOverflow中文版libdecnumber -I../libdecnumber    insn-modes.c -o insn-modes.o

cc1.exe: out of memory allocating 2239725803 bytes
make[3]: *** [insn-modes.o] Error 1
make[3]: Leaving directory `/home/root/gcc-4.2.4-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/root/gcc-4.2.4-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/root/gcc-4.2.4-build'
make: *** [all] Error 2

The main problem seems to be the call to genmodes.exe. It builds a C file (insn-modes.c) that's about 2GB in size and which, as far as I can tell is filled mostly with whitespace (though there are scattered here and there the occassional line of C code). GCC 3.4.5 chokes on it and that's how the build ends. Similar behavior is exhibited in all of the versions I've tried, except 4.5, which fails for other reasons I was hoping would be cured by using an intermediate version of the compiler.

So, three questions:

1. Has anybody else experienced this?
2. What's causing it?
3. What, if any workaround exists?

I'm trying to do this on a 64-bit Windows 7 machine.

Thanks.

Update: I've uploaded a compressed copy of two suspect files to this location. It turns out that min-insn-modes.c is also larger than it should be. The two files (over 3GB total) compress to 121KB.

---

I have the same problem; I have narrowed it down to tagged_printf in genmodes.c. I still don't know why it failed, but replacing the define of tagged_printf (from the do to and including the while) with the following solved the problem:

#define tagged_printf(FMT, ARG, TAG) printf(" " FMT ",\n", ARG)

---

insn-modes.c should not be gigantic or filled with whitespace; genmodes is malfunctioning. I don't know why it would fail that way, but I'd be very curious to have a look at insn-modes.c (if you put it in a .zip file that should shrink it down to the point where you can reasonably upload it somewhere and edit the URL into your question).

Manually stripping all the extra whitespace out of the file (tr -s ' \r\n\t\v\f' ' ') may get you something that can be compiled.

EDIT: I looked at the min-insn-modes.c you uploaded, and I think Bryan is right, there's a bug in tagged_printf: every time it's called, it's emitting something like 7 million space characters. Bryan's change should get you past this hurdle, or you could help investigate a little further by changing the definition to this:

#define tagged_printf(FMT, ARG, TAG) do { \
    int count_ = printf (" " FMT ",", ARG); \
    printf ("\t/* %s [%d], */\n", TAG, count_); \
} while (0)

That should also make your build succeed, and I'd like to see min-insn-modes.c with that change made. (No need for insn-modes.c as well.)

ADDITION: Please take a look into emit_insn_modes_h() function. It also contains printf with %n specifier which needs to be modified similarly to above:

int count_ = printf ("  %smode,", m->name);

Without this change insn-modes.h is also gets filled with a huge amount of spaces.

---

MSDN documentation says this:

Security Note The %n format is inherently insecure and is disabled by default; if %n is encountered in a format string, the invalid parameter handler is invoked as described in Parameter Validation. To enable %n support, see _set_printf_count_output.

So _set_printf_count_output(1) should fix the problem. Yes, this sucks.