This is the mail archive of the
mailing list for the GCC project.
Re: Clean up pretty printers [18/n]
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Gabriel Dos Reis <gdr at axiomatics dot org>, Paolo Carlini <paolo dot carlini at oracle dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 26 Aug 2013 09:24:11 -0500
- Subject: Re: Clean up pretty printers [18/n]
- Authentication-results: sourceware.org; auth=none
- References: <87y57o3kt5 dot fsf at euclid dot axiomatics dot org> <521B1B4F dot 5090206 at oracle dot com> <87haecdd0n dot fsf at euclid dot axiomatics dot org> <20130826122400 dot GA1859 at atrey dot karlin dot mff dot cuni dot cz> <CAAiZkiCDD4O_J20=ttih-Bes79GipG_ZnjeaXyQT8Gy4yPajYw at mail dot gmail dot com> <20130826140031 dot GA9323 at kam dot mff dot cuni dot cz>
On Mon, Aug 26, 2013 at 9:00 AM, Jan Hubicka <email@example.com> wrote:
>> On Mon, Aug 26, 2013 at 7:24 AM, Jan Hubicka <firstname.lastname@example.org> wrote:
>> > Hi,
>> > it seems to be couple weeks I am not able to compile big ltrans unit with -fdump-tree-all
>> > because the compiler eventually runs out of memory. I think it is one of your patches
>> > introducing serious memory leak. Can you, please, take a look on this? It makes my life
>> > harder - it is not fun to wait for 15 minutes for a dump and then see compiler to ICE...
>> > Thanks,
>> > Honza
>> The existing pretty printers have always had memory leaks, and
>> part of the work is to reduce that in fact :-( For example, instead
>> of printing directly to the output buffer, many of them construct
>> a string for a given formatter, then send that string to the stream,
>> and that string may or may not be reclaimed. Please give me
>> actionable instructions so I can reproduce your situation.
> I think it should be easiert to build with bootstrap-lto and then add -fdump-tree-all into
> the final link command line options.
modify ALL_LINKERFLAGS or BUILD_LINKERFLAGS?
> It seems to reproduce quite uniformlny and doesn't
> seem to be specific to my firefox builds I am doing right now…
I think I may have an idea about which existing leak is making itself
noticed but I am looking for a (semi-)automatic way to regtest it.
>> -- Gaby