When trying to compile gcc 4.8.2, cc1 tries to allocate a ludicrous amount of memory when building libgcc as part of stage 1: make all-target-libgcc 2>&1 Checking multilib configuration for libgcc... make[1]: Entering directory `/volume1/homes/nasuser/dev/dsm/build_gcc/static/armv5tel-unknown-linux-gnueabi/libgcc' # If this is the top-level multilib, build all the other # multilibs. /volume1/homes/nasuser/dev/dsm/build_gcc/static/./gcc/xgcc -B/volume1/homes/nasuser/dev/dsm/build_gcc/static/./gcc/ -B/opt2/armv5tel-unknown-linux-gnueabi/bin/ -B/opt2/armv5tel-unknown-linux-gnueabi/lib/ -isystem /opt2/armv5tel-unknown-linux-gnueabi/include -isystem /opt2/armv5tel-unknown-linux-gnueabi/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -fno-inline -I. -I. -I../.././gcc -I../../../../gcc-4.8.2/libgcc -I../../../../gcc-4.8.2/libgcc/. -I../../../../gcc-4.8.2/libgcc/../gcc -I../../../../gcc-4.8.2/libgcc/../include -DHAVE_CC_TLS -o _absvsi2.o -MT _absvsi2.o -MD -MP -MF _absvsi2.dep -DL_absvsi2 -c ../../../../gcc-4.8.2/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS cc1: out of memory allocating 4294967272 bytes after a total of 778240 bytes make[1]: *** [_absvsi2.o] Error 1 make[1]: Leaving directory `/volume1/homes/nasuser/dev/dsm/build_gcc/static/armv5tel-unknown-linux-gnueabi/libgcc' make: *** [all-target-libgcc] Error 2 Target platform is armvtel-unknown-linux-gnueabi, build configuration is as follows: configure --disable-multilib --prefix=/opt2 --disable-nls --enable-languages=c. Build directory is different from source directory hierarchy.
Which compiler did you start with? This really sounds like a bug in the original compiler if it is truly stage 1. Also can you provide the preprocessed source?
Created attachment 32435 [details] Preprocessed source as requested
The native compiler of the build system is gcc 4.2.3. An strace dump confirms that stage 1 cc1 is picked up from /volume1/homes/nasuser/dev/dsm/build_gcc/static/./gcc/ as the first -B option suggests. Running /volume1/homes/nasuser/dev/dsm/build_gcc/static/./gcc/xgcc -B/volume1/homes/nasuser/dev/dsm/build_gcc/static/./gcc/ -B/opt2/armv5tel-unknown-linux-gnueabi/bin/ -B/opt2/armv5tel-unknown-linux-gnueabi/lib/ -isystem /opt2/armv5tel-unknown-linux-gnueabi/include -isystem /opt2/armv5tel-unknown-linux-gnueabi/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -fno-inline -I. -I. -I../.././gcc -I../../../../gcc-4.8.2/libgcc -I../../../../gcc-4.8.2/libgcc/. -I../../../../gcc-4.8.2/libgcc/../gcc -I../../../../gcc-4.8.2/libgcc/../include -DHAVE_CC_TLS -DL_absvsi2 ../../../../gcc-4.8.2/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS -I../armv5tel-unknown-linux-gnueabi/libgcc/ -E >_absvsi2.i generates the attached preprocessed source. Let me know if more details are required.
PS: At first, I thought I had spotted a duplicate of #45177 but then this is no cross-compilation and #45177 has been marked "fixed" in the tracker log with the fix confirmed working.
4.2.3 is no longer supported. You should get a new binary build of GCC and try building a newer version from that.