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