Bug 16273 - [3.3/3.4/4.0 regression] Memory exhausted when using nested classes and virtual functions
Summary: [3.3/3.4/4.0 regression] Memory exhausted when using nested classes and virtu...
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.3.4
: P2 normal
Target Milestone: 3.4.2
Assignee: Mark Mitchell
Keywords: memory-hog
Depends on:
Reported: 2004-06-29 15:36 UTC by Olivier Fourdan
Modified: 2004-12-08 10:11 UTC (History)
4 users (show)

See Also:
Known to work: 2.95.3
Known to fail: 3.0.4 3.3.4 3.4.0 4.0.0
Last reconfirmed: 2004-07-03 02:41:19

Preprocessed file (gzip -9 compressed) (167.74 KB, application/x-tar)
2004-06-29 15:37 UTC, Olivier Fourdan
Unincluded, slightly reduced testcase (27.88 KB, application/octet-stream)
2004-06-29 21:49 UTC, Giovanni Bajo
More reduction (26.89 KB, application/octet-stream)
2004-06-30 12:19 UTC, Giovanni Bajo
Smaller example (only 10000 lines of code) (20.50 KB, application/octet-stream)
2004-06-30 13:48 UTC, Volker Reichelt
Original unincluded testcase (42.62 KB, application/octet-stream)
2004-08-15 02:51 UTC, Giovanni Bajo

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Fourdan 2004-06-29 15:36:33 UTC
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/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
-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:
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
Comment 1 Olivier Fourdan 2004-06-29 15:37:43 UTC
Created attachment 6650 [details]
Preprocessed file (gzip -9 compressed)
Comment 2 Volker Reichelt 2004-06-29 16:45:25 UTC
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.
Comment 3 Giovanni Bajo 2004-06-29 21:49:26 UTC
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.
Comment 4 Giovanni Bajo 2004-06-30 12:19:29 UTC
Created attachment 6663 [details]
More reduction

More reduction, still way to go.
Comment 5 Volker Reichelt 2004-06-30 13:48:20 UTC
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).
Comment 6 Volker Reichelt 2004-06-30 13:51:35 UTC
This is a regression.
I removed the hardware triples, since this can be reproduced on
i686-pc-linux-gnu as well.
Comment 7 Giovanni Bajo 2004-07-03 02:41:19 UTC
Now reduced so we can finally confirm this (thanks Volker)
Comment 8 Mark Mitchell 2004-08-12 06:29:36 UTC
Working on a (possibly partial) fix.
Comment 9 CVS Commits 2004-08-12 17:58:30 UTC
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


Comment 10 CVS Commits 2004-08-12 18:05:00 UTC
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


Comment 11 Mark Mitchell 2004-08-12 18:20:03 UTC
Fixed in GCC 3.4.2.
Comment 12 Volker Reichelt 2004-08-13 10:05:55 UTC
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.
Comment 13 Volker Reichelt 2004-08-13 10:09:57 UTC
Oops, sorry. The 130 MB is for mainline. With the 3.4 branch the memory usage
goes up to 190 MB.
Comment 14 Giovanni Bajo 2004-08-15 02:51:00 UTC
Created attachment 6931 [details]
Original unincluded testcase


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)?

Comment 15 Volker Reichelt 2004-08-19 12:43:22 UTC
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.
Comment 16 David Starks-Browning 2004-12-08 10:11:59 UTC
What about 3.3?  Can it also be fixed there?