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