/* Store information about each particular bitmap.  */
struct bitmap_descriptor
{
  const char *function;
  const char *file;
  int line;
  int allocated;
  int created;
  int peak;
  int current;
  int nsearches;
};

I guess we simply overflow current.  Using HOST_WIDEST_INT for the counters
would be appropriate.

I am unable to reproduce this problem with mainline.  I see:

cc1: out of memory allocating 4064 bytes after a total of 3543465984 bytes

I'm still seeing it with:

[lucier@descartes ~]$ /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats --with-cpu=default64
Thread model: posix
gcc version 4.4.0 20090327 (experimental) [trunk revision 145100] (GCC) 

as

[lucier@descartes compiler.i-test]$ /pkgs/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.4.0/cc1 -I../include -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common compiler.i
 btowc wctob mbrlen {GC 5325k -> 3526k} {GC 5325k -> 4483k} code_size ___H__20_compiler_2e_o1 {GC 201152k -> 113339k} ___init_proc ____20_compiler_2e_o1
Analyzing compilation unit
 {GC 181409k -> 135700k}Performing interprocedural optimizations
 <visibility> <early_local_cleanups> {GC 237979k -> 236431k} <summary generate> <inline> <static-var> <pure-const>Assembling functions:
 code_size ___init_proc ____20_compiler_2e_o1 ___H__20_compiler_2e_o1 {GC 349493k -> 288659k} {GC 406233k -> 272085k}
compiler.c: In function â:
compiler.c:322876: internal compiler error: in register_overhead, at bitmap.c:115
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

I have to admit I didn't see it with an x86-64 compiler; perhaps the ppc64 port is more complicated and requires more bitmaps.

I suspect, given the error message, that you built a 32-bit compiler and ran out of memory space before you hit this problem.

I still cannot reproduce this using the 4.4 branch:

$ ./xgcc -v
Reading specs from ./specs
Target: powerpc64-unknown-linux-gnu
Configured with: /home/bje/source/gcc-clean/configure --enable-languages=c --enable-gather-detailed-mem-stats --with-cpu=default64 --disable-bootstrap --quiet
Thread model: posix
gcc version 4.4.0 20090327 (experimental) [trunk revision 145326] (GCC) 

$ ./cc1 -I../include -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common  compiler.i
 btowc wctob mbrlen code_size ___H__20_compiler_2e_o1 {GC 124407k -> 67811k} ___init_proc ____20_compiler_2e_o1
Analyzing compilation unit
 {GC 107701k -> 81846k}Performing interprocedural optimizations
 <visibility> <early_local_cleanups> {GC 140505k -> 139614k} <summary generate> <inline> <static-var> <pure-const>Assembling functions:
 code_size ___init_proc ____20_compiler_2e_o1 ___H__20_compiler_2e_o1 {GC 188952k -> 155976k} {GC 232824k -> 158800k}
cc1: out of memory allocating 4064 bytes after a total of 3485597696 bytes

Can you see any differences here?

You have --disable-bootstrap, so my guess is that cc1 is a 32-bit binary if that's what your system compiler builds by default.  By bootstrapping you get a 64-bit binary (the first cc1 built in the bootstrap is 32-bit, but the second and third are 64-bit).

Just for more information, I now hit this on x86_64-unknown-linux-gnu with the compiler

pythagoras-32% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /tmp/lucier/gcc/mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats
Thread model: posix
gcc version 4.5.0 20090508 (experimental) [trunk revision 147288] (GCC) 

on the compiler.i test case with

/pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I.  -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -frename-registers -fno-move-loop-invariants -fforward-propagate -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -c compiler.i -ftime-report -fmem-report > & rename-no-move-loop-invariants-forward-propagate-report-new

The test case does not run in a GB of RAM on my x86-64 system.  It sends the system deep into swap until the out-of-memory manager kicks in.

Created attachment 17876 [details]
patch to use HOST_WIDEST_INT for bitmap statistics

Here's a hack to use HOST_WIDEST_INT for bitmap statistics.  I'll attach the report from the compiler.i test case.  If you think the report is useful, perhaps you can use this as a starting point for a real patch and I'll bootstrap and test it.

Brad

Created attachment 17877 [details]
memory and time report for compiler.i test case

Here's the output for the test case.  See if you like it.

I used the following configure command and compiler version:

pythagoras-147% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /tmp/lucier/gcc/mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats --disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090515 (experimental) [trunk revision 147594] (GCC)

The patch is good enough.

Created attachment 17880 [details]
The regression test results

So it's passed bootstrap and regression tested.

configure flags: --prefix=/pkgs/gcc-mainline --enable-gather-detailed-mem-stats
Results for 4.5.0 20090515 (experimental) [trunk revision 147594] (GCC) testsuite on x86_64-unknown-linux-gnu

I don't have check-in privileges.

Please post it to gcc-patches with an appropriate ChangeLog entry.  Thanks.

Subject: Re:  ICE in register_overhead, at bitmap.c:115


On May 13, 2009, at 9:32 PM, bje at gcc dot gnu dot org wrote:

> The test case does not run in a GB of RAM on my x86-64 system.  It  
> sends the
> system deep into swap until the out-of-memory manager kicks in.

Ah, now that -fforward-propagate has been added to -O1 on mainline it  
takes a bit over 8GB of RAM to run instead of a GB.

Sorry.

Subject: Bug 39301

Author: hjl
Date: Sat May 16 22:42:15 2009
New Revision: 147624

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147624
Log:
2009-05-16  Brad Lucier  <lucier@math.purdue.edu>

	PR middle-end/39301
	* hwint.h: Add macro HOST_WIDEST_INT_PRINT.
	* bitmap.c (bitmap_descriptor): Make fields HOST_WIDEST_INT.
	(output_info): Make field HOST_WIDEST_INT.
	(print_statistics): Use HOST_WIDEST_INT_PRINT.
	(dump_bitmat_statistics): Same.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/bitmap.c
    trunk/gcc/hwint.h

Fixed by

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147624