The (preprocessed) code attached produces various effects with GCC. * gcc-3.0.4 (causes an ICE in GCC, "Internal compiler error in build_secondary_vtable, at cp/class.c:865") * gcc-3.3 (Virtual Memory exhausted) * gcc-3.3.4 (Virtual Memory exhausted) * gcc-3.4.0 (Virtual Memory exhausted) The same code was compiling with GCC 2.95 using about 150Mb of RAM. The attached preprocessed files is generated with gcc-3.3.4 on Solaris 8 but the same problem occurs with other GCC version on Linux. Current Host: SunOS solaris8 5.8 Generic_108528-18 sun4u sparc SUNW,Ultra-5_10 System Configuration: Sun Microsystems sun4u Memory size: 256 Megabytes Reading specs from /opt/gcc-3.3.4/lib/gcc-lib/sparc-sun-solaris2.8/3.3.4/specs Configured with: ../gcc-3.3.4/configure --prefix=/opt/gcc-3.3.4 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-languages=c,c++ --enable-threads=posix --enable-static Thread model: posix gcc version 3.3.4 /opt/gcc-3.3.4/lib/gcc-lib/sparc-sun-solaris2.8/3.3.4/cc1plus -E -D__GNUG__=3 -quiet -v -I/opt/X11R6/include -I/netma/dnetma/_solaris/include/motif1.2.2/include -I/local/tmp/rantanplan/dll/src -I/local/tmp/rantanplan/dll/include -I/local/tmp/rantanplan/dll/srcGene -I/local/tmp/rantanplan/dll/includeGene -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -Dsparc -D__sparc__ -D__sparc -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc -Dsparc -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DGUI_INTERFACE -DXTI_COMMUNICATOR -DIMPLEMENT_DLL_INTERFACE -DDOMAIN_NAME=netma /local/tmp/rantanplan/dll/srcGene/corba_transaction_cluster_iCB_Dll.cc -Wno-deprecated -fpermissive -fpic -fPIC -fno-external-templates -fno-inline -fno-default-inline -ftemplate-depth-99 corba_transaction_cluster_iCB_Dll.ii cc1plus: warning: switch "-fno-external-templates" is deprecated, please see documentation for details ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/opt/gcc-3.3.4/sparc-sun-solaris2.8/include" #include "..." search starts here: #include <...> search starts here: /opt/X11R6/include /netma/dnetma/_solaris/include/motif1.2.2/include /local/tmp/rantanplan/dll/src /local/tmp/rantanplan/dll/include /local/tmp/rantanplan/dll/srcGene /local/tmp/rantanplan/dll/includeGene /opt/gcc-3.3.4/include/c++/3.3.4 /opt/gcc-3.3.4/include/c++/3.3.4/sparc-sun-solaris2.8 /opt/gcc-3.3.4/include/c++/3.3.4/backward /opt/gcc-3.3.4/include /opt/gcc-3.3.4/lib/gcc-lib/sparc-sun-solaris2.8/3.3.4/include /usr/include End of search list. /opt/gcc-3.3.4/lib/gcc-lib/sparc-sun-solaris2.8/3.3.4/cc1plus -fpreprocessed corba_transaction_cluster_iCB_Dll.ii -quiet -dumpbase corba_transaction_cluster_iCB_Dll.cc -auxbase-strip bin/corba_transaction_cluster_iCB_Dll.o -g -Wno-deprecated -version -fpermissive -fpic -fPIC -fno-external-templates -fno-inline -fno-default-inline -ftemplate-depth-99 -o corba_transaction_cluster_iCB_Dll.s cc1plus: warning: switch "-fno-external-templates" is deprecated, please see documentation for details GNU C++ version 3.3.4 (sparc-sun-solaris2.8) compiled by GNU C version 3.3. GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768
Created attachment 6650 [details] Preprocessed file (gzip -9 compressed)
I tried 3.3.4 on i686-pc-linux-gnu. It used about 1 GB of memory before I killed it. With 3.4.0 I got some errors first, but the compiler kept doing its job and the memory usage went up to 2 GB within seconds before I also killed it. To me this looks more like an infinite loop instead of a memory-hog.
Created attachment 6657 [details] Unincluded, slightly reduced testcase I am attacching an unincluded testcase which I have reduced a little, but still way to go. If someone wants to get on reducing this, be my guest, I don't have more time right now.
Created attachment 6663 [details] More reduction More reduction, still way to go.
Created attachment 6664 [details] Smaller example (only 10000 lines of code) After some reduction I came up with the attached example. And now I'm convinced that this is really just a memory-hog. Just have a look at the memory usage and compilation times: gcc 2.95.3: 15MB 2.87s gcc 3.0: segfault gcc 3.0.4: ICE in build_secondary_vtable, at cp/class.c gcc 3.1: 82MB 11.17s gcc 3.2.3: 82MB 11.22s gcc 3.3: 334MB 72.07s gcc 3.3.4: 334MB 70.58s gcc 3.4.0: 554MB 10.52s 3.4 branch: 554MB 10.52s head: 654MB 10.16s lno branch: 655MB 10.45s This is an increase in memory usage by a factor of 44 sinc gcc 2.95.3 !!!! It's no surprise that this goes beyond 2GB with a larger example. :-( Adding "-fsyntax-only" on the command-line doesn't help. Btw, the reduced example is all about nested classes, inheritance and virtual functions. It compiles without errors since gcc 2.95.3 (with the exception that the 3.0 branch crashes). I got rid of all static member funtions and most (if not all) function definitions (as opposed to declarations).
This is a regression. I removed the hardware triples, since this can be reproduced on i686-pc-linux-gnu as well.
Now reduced so we can finally confirm this (thanks Volker)
Working on a (possibly partial) fix.
Subject: Bug 16273 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2004-08-12 17:58:25 Modified files: gcc/cp : ChangeLog class.c Log message: PR c++/16273 * class.c (count_depth_data): New type. (dfs_depth_post): New function. (dfs_depth_q): Likewise. (find_final_overrider_data_s): Change type of vpath. Add vpath_list. (dfs_find_final_overrider_1): New function. (dfs_find_final_overrider): Use it. (dfs_find_final_overrider_q): Adjust use of vpath. (dfs_find_final_overrider_post): Likewise. (find_final_overrider): Use dfs_depth. Allocate and deallocate vpath_list. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4273&r2=1.4274 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.650&r2=1.651
Subject: Bug 16273 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: mmitchel@gcc.gnu.org 2004-08-12 18:04:55 Modified files: gcc/cp : ChangeLog class.c Log message: PR c++/16273 * class.c (count_depth_data): New type. (dfs_depth_post): New function. (dfs_depth_q): Likewise. (find_final_overrider_data_s): Change type of vpath. Add vpath_list. (dfs_find_final_overrider_1): New function. (dfs_find_final_overrider): Use it. (dfs_find_final_overrider_q): Adjust use of vpath. (dfs_find_final_overrider_post): Likewise. (find_final_overrider): Use dfs_depth. Allocate and deallocate vpath_list. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.145&r2=1.3892.2.146 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.595.4.8&r2=1.595.4.9
Fixed in GCC 3.4.2.
For the record: With the example from comment #5 I now get: 3.4 branch: 50MB 6.5s head: 40MB 5.2s Compiling the original example with 3.4 branch on i686-pc-linux-gnu gives a lot of error messages. But the compiler seems to keep doing its job while the memory usage is staying below 130 MB.
Oops, sorry. The 130 MB is for mainline. With the 3.4 branch the memory usage goes up to 190 MB.
Created attachment 6931 [details] Original unincluded testcase Volker, I'm attacching the original unincluded testcase, which should be mostly compiler-independent. I tried and it compiles with a rather old 3.4, so it should do ok (you can also try with -fpermissive). Can you please check if the bug is indeed fixed also with this version, and how the memory figures are, compared to older versions (especially 2.95)? Thanks
With minor corrections I could compile the unincluded testcase with basically the same memory usage as in comment #13: 130 MB for mainline, 190 MB for 3.4 branch. I even managed to compile it with -O2. That just added another 8MB. With 2.95.3 memory usage peeks at about 95 MB (-O and -O2). I think we can live with the 50% increase for such complex code.
What about 3.3? Can it also be fixed there?