------- Comment #83 from dberlin at gcc dot gnu dot org 2009-02-04 18:24 ------- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines
These numbers claim a leak of the graph->preds bitmap (and related bitmaps) which are quite clearly freed all the time. These bitmaps are allocated onto the predbitmap obstack, which is released through remove_preds_and_fake_succs. It always executes, so i have trouble understanding why it considers this a leak. On Wed, Feb 4, 2009 at 12:28 PM, lucier at math dot purdue dot edu <gcc-bugzi...@gcc.gnu.org> wrote: > > > ------- Comment #82 from lucier at math dot purdue dot edu 2009-02-04 17:28 > ------- > I still have the bitmap.c patch from > > http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html > > in my tree so I don't get meaningless statistics for bitmaps. (Kenny > installed > in the trunk something like the patch above for alloc-pool.c.) > > There are more bitmaps allocated than on 2008-09-26 (13GB instead of 12GB). > > 3GB was allocated in alloc-pool. > > Execution time was worse, 228.17 user seconds versus 168 seconds. > > I didn't watch top to estimate the maximum memory usage. > > This is with > > euler-8% /pkgs/gcc-mainline/bin/gcc -v > Using built-in specs. > Target: x86_64-unknown-linux-gnu > Configured with: ../../mainline/configure --enable-checking=release > --prefix=/pkgs/gcc-mainline --enable-languages=c > --enable-gather-detailed-mem-stats > Thread model: posix > gcc version 4.4.0 20090204 (experimental) [trunk revision 143922] (GCC) > > Brad > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854