This problem did not exist in 4.6.x. The following program uses > 4 GiB of memory (more than my system has) during compilation. If I reduce the size of the array a bit, it still uses several GiB but does eventually compile (so the problem is not infinite recursion) and takes a very long time to compile. Compiling with optimizations on seems to eliminate the large memory usage but takes longer than I was willing to wait to compile. class Class { public: Class() {} }; int main() { Class table [2048][256] = {}; return 0; } Using something like int causes no problems and compiles quickly. This may also relate to a C++11 missed optimization opportunity, because this may suggest that the fact that Class has a constructor is making it non-POD, but the POD rules were relaxed in C++11 to make Class a POD structure (I think). Compiling with std=c++11 doesn't fix the problem, however. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)
It is caused by revision 180944: http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00230.html
Turns out that contrary to my previous report, optimizations don't actually solve the memory use problem, they just slow it down significantly. Several hours into compilation, memory use was at ~2 GiB and still growing (very slowly). It seems that maybe it uses just as much memory, it just takes much, much longer to get there.
(In reply to comment #1) > It is caused by revision 180944: Specifically, the "Don't use build_aggr_init for aggregate initialization of arrays." part.
*** Bug 53666 has been marked as a duplicate of this bug. ***
As a workaround for this bug, I was able to compile much faster (so that I can compile my program with optimizations turned on) by declaring the constructor for the class in the array as constexpr (which worked just fine for me because I only cared that a single member variable was 0, and the rest could have indeterminate values).
GCC 4.7.2 has been released.
Author: jason Date: Thu Jan 3 16:51:41 2013 New Revision: 194860 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194860 Log: PR c++/53650 * call.c (type_has_extended_temps): New. * cp-tree.h: Declare it. * decl.c (check_initializer): Use build_aggr_init for arrays if it is false. * init.c (build_vec_init): Avoid mixed signed/unsigned arithmetic. Added: trunk/gcc/testsuite/g++.dg/init/array34.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c
Fixed for 4.8 so far. Waiting a bit before applying the fix to 4.7.
Author: jason Date: Tue Jan 22 16:28:58 2013 New Revision: 195380 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195380 Log: PR c++/53650 * call.c (type_has_extended_temps): New. * cp-tree.h: Declare it. * decl.c (check_initializer): Use build_aggr_init for arrays if it is false. * init.c (build_vec_init): Avoid mixed signed/unsigned arithmetic. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/array34.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/cp/cp-tree.h branches/gcc-4_7-branch/gcc/cp/decl.c branches/gcc-4_7-branch/gcc/cp/init.c
Fixed.
(In reply to comment #9) > Author: jason > Date: Tue Jan 22 16:28:58 2013 > New Revision: 195380 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195380 > Log: > PR c++/53650 > * call.c (type_has_extended_temps): New. > * cp-tree.h: Declare it. > * decl.c (check_initializer): Use build_aggr_init for arrays > if it is false. > * init.c (build_vec_init): Avoid mixed signed/unsigned arithmetic. > > Added: > branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/array34.C > Modified: > branches/gcc-4_7-branch/gcc/cp/ChangeLog > branches/gcc-4_7-branch/gcc/cp/call.c > branches/gcc-4_7-branch/gcc/cp/cp-tree.h > branches/gcc-4_7-branch/gcc/cp/decl.c > branches/gcc-4_7-branch/gcc/cp/init.c this patch breaks bootstrap: ../../gcc/cp/call.c: In function 'type_has_extended_temps': ../../gcc/cp/call.c:8852:7: error: 'for' loop initial declarations are only allowed in C99 mode ../../gcc/cp/call.c:8852:7: note: use option -std=c99 or -std=gnu99 to compile your code
Author: jason Date: Wed Jan 23 02:48:00 2013 New Revision: 195397 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195397 Log: PR c++/53650 * call.c (type_has_extended_temps): Fix C++ism. Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c