On Sat, Aug 18, 2012 at 12:39 PM, Richard Guenther
wrote:
> On Sat, Aug 18, 2012 at 12:28 PM, Steven Bosscher
> wrote:
>> On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote:
>>> I filled a small bug report at
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313
>>
>> Yup, thanks.
>>
>>
On Sat, Aug 18, 2012 at 12:28 PM, Steven Bosscher wrote:
> On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote:
>> I filled a small bug report at
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313
>
> Yup, thanks.
>
> * dse.c (dse_step7): Don't free kill_on_calls bitmap, it is
> freed
On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote:
> I filled a small bug report at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313
Yup, thanks.
* dse.c (dse_step7): Don't free kill_on_calls bitmap, it is
freed when its obstack is release.
Index: dse.c
==
Steven Bosscher wrote:
On Sat, Aug 18, 2012 at 9:01 AM, Tobias Burnus wrote:
I think it's your patch which breaks bootstrapping here:
Program received signal SIGSEGV, Segmentation fault.
0x005bfa40 in bitmap_obstack_free (map=0x18693a0) at
/projects/tob/gcc-git/gcc/gcc/bitmap.c:388
388
On Sat, Aug 18, 2012 at 9:01 AM, Tobias Burnus wrote:
> Steven Bosscher wrote:
>>
>> This reduces peak memory usage for the small test case of PR54146
>> Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk?
>
>
> I think it's your patch which breaks bootstrapping here:
>
> Checking multi
Steven Bosscher wrote:
This reduces peak memory usage for the small test case of PR54146
Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk?
I think it's your patch which breaks bootstrapping here:
Checking multilib configuration for libgcc...
...
checking for suffix of object files
On Fri, Aug 17, 2012 at 9:03 AM, Steven Bosscher wrote:
> Hello,
>
> This reduces peak memory usage for the small test case of PR54146 by
> 2GB. 24hrs ago peak memory was 9.4 GB in top, but with Richi's patches
> from yesterday and with this one, peak memory is now "only" 5.2GB.
> About 40% of tha
Hello,
This reduces peak memory usage for the small test case of PR54146 by
2GB. 24hrs ago peak memory was 9.4 GB in top, but with Richi's patches
from yesterday and with this one, peak memory is now "only" 5.2GB.
About 40% of that is in IRA and reload so there is still room for
improvement, but c
