https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
--- Comment #19 from David Malcolm <dmalcolm at gcc dot gnu.org> --- Parsing textual gcc diagnostics is non-trivial. FWIW, as noted on the gcc list, I had a go at creating an interchange format for static analysis results (which includes compiler diagnostics). The aim was to run lots of static analyzers on lots of code, and capture the results in a consistent format in a browseable database, hence the need for an interchange format. [1] I created a format I call "Firehose": https://github.com/fedora-static-analysis/firehose as a set of Python classes that can be roundtripped through XML and JSON. It currently provides parsers for the output of gcc, clang-analyzer, cppcheck, and findbugs, and my gcc-python-plugin has a branch that can emit firehose reports directly. It can store more than just location+message: clang-analyzer can emit a series of messages describing a trace of events leading to a bug, and firehose can capture that (by reading the plist file). We don't provide that yet from gcc, but it might be worth thinking about. The gcc diagnostic parser is here: https://github.com/fedora-static-analysis/firehose/blob/master/firehose/parsers/gcc.py with test cases: https://github.com/fedora-static-analysis/firehose/blob/master/tests/parsers/test_gcc_parser.py
