g++ memory bug.

[Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>]

The following small test case exhibits a huge memory explosion with g++ when 
using recursive templates and inlining. I understand that there might 
be some heap explosion (since sizeof(X<36>) is 1 the heap if fully 
inlined can grow up to 2^36 even if in this case unused variables 
elimination should avoid this problem). Do we have a way to control the inline 
depth ??

For what it's worth, Kai C++ compiles the program without any pb...

This seems to be orthogonal to the problems that Mark Mitchell had 
mentionned before so it might be something new ???

Here is the code:

>cat MemBug.C

template <int n>
class X {

public:
  
  X() {
#	ifdef M1
    X<n-1> x;            //   0Mb
#	endif
#	ifdef M2
    X<n-1> x, y;         // 250Mb
#	endif
  }
};

template <>
class X<0> {
};

int main() {
  X<36> x; //internal compiler error
}

> g++ -v
Reading specs from /u/corse/2/robotvis/gnu/bin/egcs/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.92.20/specs
gcc version egcs-2.92.20 19981109 (gcc2 ss-980609 experimental)

> g++ -ftemplate-depth-100 -O4 -DM1 MemBug.C
#works fine and uses almost no memory.

> g++ -ftemplate-depth-100 -O4 -DM2 MemBug.C
g++: Internal compiler error: program cc1plus got fatal signal 11

The programs eats up to 250Mb of memory before crashing... At least 
there should be a reasonnable error message.
(By the way putting the two X<n-1> variables as members which indeed
 results in a memory explosion for the object gives a crash where it
 should give something like "Object too large" (Kai's behaviour)).

The same problem is repeatable with the same compiler with
an i686-pc-linux-gnulibc1 machine.

Compiling with -fno-inline always succeeds...

Here is a trace with linux:

(gdb) run MemBug.i -O4 -ftemplate-depth-100 
Starting program: /u/corse/2/robotvis/gnu/bin/egcs/lib/gcc-lib/i686-pc-linux-gnulibc1/egcs-2.92.20/cc1plus MemBug.i -O4 -ftemplate-depth-100
warning: Unable to find dynamic linker breakpoint function.
warning: GDB will be unable to debug shared library initializers
warning: and track explicitly loaded dynamic code.
 X<n>::X() int main() X<36>::X() X<35>::X() X<34>::X() X<33>::X() X<32>::X() X<31>::X() X<30>::X() X<29>::X() X<28>::X() X<27>::X() X<26>::X() X<25>::X() X<24>::X() X<23>::X() X<22>::X() X<21>::X() X<20>::X() X<19>::X() X<18>::X() X<17>::X() X<16>::X() X<15>::X() X<14>::X() X<13>::X() X<12>::X() X<11>::X() X<10>::X() X<9>::X() X<8>::X() X<7>::X() X<6>::X() X<5>::X() X<4>::X() X<3>::X() X<2>::X() X<1>::X()
Program received signal SIGSEGV, Segmentation fault.
expand_inline_function (fndecl=0x8295758, parms=0x828f480, target=0x0, 
    ignore=1, type=0x8291c80, structure_value_addr=0x0)
    at ../../egcs/gcc/integrate.c:1557
1557      bzero ((char *) map->const_equiv_map,

Does someone has an idea or a patch ??
 
 --------------------------------------------------------------------
 Theodore Papadopoulo
 Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------