Small testcase demonstrating template-free memory explosion problem.

[Corey Kosak]

> This test case does not blow up for me with -O2.  It uses less than
> 5MB of memory.  It's possible that either you don't have some patch
> that I submitted, or that there's a problem on alpha-dec-osf3.2 that's
> not visible on i686-pc-linux-gnu.  I'm not sure where to go from here.


Wow, that's really strange!  But indeed, my experience is the same as yours:
Using freshly untarred (just egcs-core and egcs-g++) and then compiled
egcs-971225 with no additional patches installed:


Linux takes less than 5M....

% g++ -v
Reading specs from /home/kosak/loco/lib/gcc-lib/i686-pc-linux-gnulibc1/egcs-2.91.03/specs
gcc version egcs-2.91.03 971225 (gcc-2.8.0)
% limit datasize 5M
% g++ -O2 big.cc


Whereas alpha_osf32 wants more than 300M

% g++ -v
Reading specs from /usr2/aloco/lib/gcc-lib/alpha-dec-osf3.2/egcs-2.91.03/specs
gcc version egcs-2.91.03 971225 (gcc-2.8.0)
% limit datasize 300M
% g++ -O2 big.cc
big.cc: In function `int main()':
big.cc:59: virtual memory exhausted



And so does alpha_osf40

% g++ -v
Reading specs from /scratch/kosak/loco/lib/gcc-lib/alphaev56-dec-osf4.0c/egcs-2.91.03/specs
gcc version egcs-2.91.03 971225 (gcc-2.8.0)
% limit datasize 300M
% g++ -O2 big.cc
big.cc: In function `int main()':
big.cc:59: virtual memory exhausted




Random thought: could this problem be due to an improper use of alloca()
somewhere?  gcc uses alloca() a lot, and this intriguing warning appears in
the man page for OSF alloca:

                                     Note

       The alloca() function requires inclusion of <alloca.h>.  Without
       this header file, alloca() allocates memory in the heap instead
       of the stack; this memory is not necessarily freed when the cal-
       ling routine exits.


Otherwise I have no idea, but if someone more knowledgeable is interested in
looking into this, I'd be happy to give him/her an account on a fast
big-memory alpha.