Re: [PATCH] Kill -fdump-translation-unit

2017-05-11 Thread Rainer Orth
Hi Nathan, > On 05/11/2017 01:33 PM, Rainer Orth wrote: > >> unfortunately, this part >> >> * graphite-poly.c: Don't include tree-dump.h. >> >> broke bootstrap with graphite: > > oh, that has to be configured enabled? I've committed this that I think is right: it requires an appropriate ver

Re: [PATCH] Kill -fdump-translation-unit

2017-05-11 Thread Nathan Sidwell
On 05/11/2017 01:33 PM, Rainer Orth wrote: unfortunately, this part * graphite-poly.c: Don't include tree-dump.h. broke bootstrap with graphite: oh, that has to be configured enabled? I've committed this that I think is obvious. looks to be another case of using tree-dumph to get

Re: [PATCH] Kill -fdump-translation-unit

2017-05-11 Thread Rainer Orth
Hi Nathan, > On 05/10/2017 04:49 AM, Richard Biener wrote: >> On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell wrote: >>> -fdump-translation-unit is an inscrutably opaque dump. It turned out that >>> most of the uses of the tree-dump header file was to indirectly get at >>> dumpfile.h, and the dum

Re: [PATCH] Kill -fdump-translation-unit

2017-05-11 Thread Nathan Sidwell
On 05/10/2017 04:49 AM, Richard Biener wrote: On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell wrote: -fdump-translation-unit is an inscrutably opaque dump. It turned out that most of the uses of the tree-dump header file was to indirectly get at dumpfile.h, and the dump_function entry point it

Re: [PATCH] Kill -fdump-translation-unit

2017-05-10 Thread Nathan Sidwell
On 05/10/2017 01:58 PM, Jakub Jelinek wrote: A quick search indicates that people have published .tu parsers in Perl, JS (producing json), the person objecting on IRC apparently used Python, and I'm aware of another Python-based parser by Bruce Merry. Prior to Alex mentioning it, I was unaware

Re: [PATCH] Kill -fdump-translation-unit

2017-05-10 Thread Alexander Monakov
On Wed, 10 May 2017, Jakub Jelinek wrote: > Can it at least be taken out of -fdump-tree-all? It is huge, often larger > than the sum of all the other dump files, and don't remember ever using it > for anything. Yes, apart from advertising the capability I don't imagine it's useful to produce that

Re: [PATCH] Kill -fdump-translation-unit

2017-05-10 Thread Jakub Jelinek
On Wed, May 10, 2017 at 08:51:22PM +0300, Alexander Monakov wrote: > On Wed, 10 May 2017, Richard Biener wrote: > > > On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell wrote: > > > -fdump-translation-unit is an inscrutably opaque dump. It turned out that > > > most of the uses of the tree-dump head

Re: [PATCH] Kill -fdump-translation-unit

2017-05-10 Thread Alexander Monakov
On Wed, 10 May 2017, Richard Biener wrote: > On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell wrote: > > -fdump-translation-unit is an inscrutably opaque dump. It turned out that > > most of the uses of the tree-dump header file was to indirectly get at > > dumpfile.h, and the dump_function entry

Re: [PATCH] Kill -fdump-translation-unit

2017-05-10 Thread Richard Biener
On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell wrote: > -fdump-translation-unit is an inscrutably opaque dump. It turned out that > most of the uses of the tree-dump header file was to indirectly get at > dumpfile.h, and the dump_function entry point it had forwarded to a dumper > in tree-cfg.c.

[PATCH] Kill -fdump-translation-unit

2017-05-09 Thread Nathan Sidwell
-fdump-translation-unit is an inscrutably opaque dump. It turned out that most of the uses of the tree-dump header file was to indirectly get at dumpfile.h, and the dump_function entry point it had forwarded to a dumper in tree-cfg.c. The gimple dumper would use its node dumper when asked for