GCC Compiler ↔ IDE Integration: Can GCC Emit Diagnostics as Machine-Readable JSON for Accessible Tooling?

Short answer

Yes — GCC can emit machine-readable diagnostics, and the supported format is SARIF (Static Analysis Results Interchange Format), a JSON-based OASIS standard. Use -fdiagnostics-format=sarif (or -fdiagnostics-format=sarif-file to write to a file). There is no stable, documented -fdiagnostics-json option in GCC releases; references you have seen are to proposals and patches that did not land as a generic JSON format. SARIF is the intended contract.

Which GCC release shipped it

SARIF output was introduced by David Malcolm's diagnostic-format work and first appeared in GCC 13 (2023), where it is documented in the GCC manual under -fdiagnostics-format= with values text, sarif-stderr, sarif-file, and sarif. Earlier releases (GCC 12 and below) have no supported structured format — only the human-oriented text output plus -fdiagnostics-parseable-fixits, which prints fix-it hints in a line-oriented, greppable form but is not a schema. If your toolchain is pinned to GCC 13+, you are on the supported path; treat anything older as text-only.

What's in the SARIF payload

GCC's SARIF emission includes, per diagnostic: the rule/warning name, severity level, the message text, and physicalLocation with artifact URI, line, and column. Fix-it hints are represented as SARIF fixes with artifactChanges/replacements, and multi-range diagnostics (e.g., mismatched macro expansion sites, secondary notes) appear as related locations. Two caveats before you build on this:

• Coverage is not uniform. SARIF support is newer than the text emitter, and fix-it/range completeness varies by diagnostic type. Some warnings carry rich ranges; others degrade to a single point location. Verify against the specific warnings you care about rather than assuming parity with Clang's diagnostic engine.
• LSP is a different shape. SARIF is a static-analysis interchange document (a whole runs array with results); LSP diagnostics are incremental textDocument/publishDiagnostics notifications keyed by URI. GCC emits the former; no LSP client consumes it directly over JSON-RPC.

Do you still need an adapter?

Yes, for a live LSP integration. The practical options:

1. Batch adapter: run the build with -fdiagnostics-format=sarif-file, then translate SARIF results into LSP Diagnostic objects (map level → severity, physicalLocation.region → range, fixes → code actions). This is straightforward and is essentially what SARIF viewer extensions do.
2. Existing language server: for C/C++ editing in VS Code, clangd reading your compile_commands.json already delivers LSP-native diagnostics with fix-its — but note these come from Clang's engine, so warning wording and coverage differ from your GCC build. If the goal is that IDE squiggles match CI output exactly, the SARIF adapter is the honest route.
3. Accessibility layer: for screen readers and structured error lists, SARIF is directly consumable — no LSP hop needed. A small script that flattens results into an ordered, navigable list is sufficient.

Verifying conformance

GCC does not ship a conformance checker, but verification is cheap:

gcc -fdiagnostics-format=sarif-file broken.c
python3 -m json.tool broken.c.sarif > /dev/null   # well-formed JSON?

Then validate the structure against the OASIS SARIF 2.1.0 schema (available from the OASIS SARIF TC / schemastore) with any JSON Schema validator, and open the file in the SARIF Viewer VS Code extension to confirm locations map to the right lines. A known-error fixture file with one warning, one error, and one fix-it hint makes a good regression test across GCC upgrades.

Bottom line

GCC 13+ gives you a documented, schema-backed JSON diagnostics format via SARIF — no regex scraping required. What it does not give you is a live LSP feed: plan on a thin translation layer (or a SARIF-aware viewer) between the compiler and your IDE or accessibility tooling, and spot-check fix-it coverage for the specific warnings your project enables.