On 07/25/2018 08:59 AM, David Malcolm wrote: > On Tue, 2018-07-24 at 16:11 +0200, Richard Biener wrote: >> On Mon, Jul 23, 2018 at 9:20 PM David Malcolm <dmalc...@redhat.com> >> wrote: >>> >>> On Mon, 2018-07-23 at 11:46 +0200, Richard Biener wrote: >>>> On Fri, Jul 20, 2018 at 6:27 PM David Malcolm <dmalc...@redhat.co >>>> m> >>>> wrote: >>>>> >>>>> This patch adds a Python 3 module to "contrib" for reading the >>>>> output of >>>>> -fsave-optimization-record. >>>>> >>>>> It can be imported from other Python code, or run standalone as >>>>> a >>>>> script, >>>>> in which case it prints the saved messages in a form resembling >>>>> GCC >>>>> diagnostics. >>>>> >>>>> OK for trunk? >>>> >>>> OK, but shouldn't there maybe a user-visible (and thus installed) >>>> tool for >>>> this kind of stuff? Which would mean to place it somewhere else. >>> >>> As well as this support code, I've got code that uses it to >>> generate >>> HTML reports. I'm thinking that all this Python code might be >>> better >>> to maintain in an entirely separate repository, as a third-party >>> project (maintained by me, under some suitable Free Software >>> license, >>> accessible via PyPI), since I suspect that the release cycle ought >>> to >>> be different from that of gcc itself. >>> >>> Would that be a better approach? >> >> Possibly. >> >> Richard. > > [CCing Rainer and Mike] > > A related matter that may affect this: currently there's not much test > coverage for -fsave-optimization-record in trunk (sorry). > > "trunk" currently has: > > (a) selftest::test_building_json_from_dump_calls, which captures the > results of some dump calls, and does very minimal textual verification > of the JSON that would be emitted by -fsave-optimization-record. > > (b) gcc.c-torture/compile/pr86636.c, which merely verifies that we > don't ICE with a particular usage of -fsave-optimization-record. > > Ideally we'd have some test coverage of the file written out by -fsave- > optimization-record: that it's valid JSON, that it conforms to the > expected internal structure, and that the expected data is correct and > complete (relative to some known dump calls; I have a plugin for > testing this if need be, in gcc.dg/plugins). > > I don't know if Tcl has any JSON support, but in Python, JSON support > is built-in to the standard library, so I wonder if there's a case for > having a DejaGnu directive to (optionally) call out to a Python script > to check the JSON file that's been written, using this optrecord.py > module to handle loading the JSON. Doing so would implicitly check > that that the emitted adheres to the expected internal structure, and > the script could add additional testcase-specific verifications. > > The directive would have to check for the presence of Python, and emit > an UNSUPPORTED if unavailable. I'd support this. When a suitable python isn't available it fails gracefully and gives us independent testing that the resulting bits are proper JSON.
jeff