On Fri, 2026-02-27 at 07:37 +0100, Richard Biener wrote: > On Thu, Feb 26, 2026 at 5:38 PM David Malcolm <[email protected]> > wrote: > > > > Richi/Jakub: OK if I apply these patches to trunk now, or should I > > wait > > until next stage 1? > > It's OK - I trust you with the idea whether this will break sth or > not.
Thanks. I rebased and refreshed the patches to fix a minor conflict with Soumya's r16-7755-g622b68c6e14b9c, verified boostrap®test on x86_64-pc-linux-gnu, and verified make check-gcc RUNTESTFLAGS="aarch64- json-tunings.exp=*" with --target=aarch64-unknown-linux-gnu. I've pushed these 5 patches as r16-7819-gd88eb2e961e5ee through r16- 7823-g5d12019d75b196. Soumya: I merely fixed the conflict with r16-7755-g622b68c6e14b9c; I haven't updated that new warning to use json_warning (it's late here). I can take a look at that next week, or maybe you can do it? Dave > > Richard. > > > https://gcc.gnu.org/pipermail/gcc-patches/2026-February/708500.html > > > > * successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > * verified make check-gcc RUNTESTFLAGS="aarch64-json-tunings.exp=*" > > with --target=aarch64-unknown-linux-gnu > > * hand-verified SARIF and HTML output > > * hand-verified that valgrind is clean > > > > I believe this has been approved by the aarch64 maintainers (albeit > > needing a regeneration of aarch64-json-tunings-parser- > > generated.inc), > > and Soumya just posted another patch in this area that mentioned > > wanting to use the diagnostic improvements: > > https://gcc.gnu.org/pipermail/gcc-patches/2026-February/709295.html > > > > > > Thanks > > Dave > > > > On Sat, 2026-02-14 at 10:51 -0500, David Malcolm wrote: > > > I added JSON parsing code in GCC 15 to support sarif-replay. > > > > > > In GCC 16 the aarch64 target has gained the ability to load > > > tuning > > > information in JSON form via -muser-provided-CPU=FILENAME.json > > > (see > > > r16-5615-g59f37983222d86 through r16-5619-ga0b8cc4a473e1e). > > > > > > The UX is currently rather poor for malformed and invalid inputs > > > to > > > -muser-provided-CPU=: > > > > > > $ ./xgcc -B. -S test.c -muser-provided-CPU=malformed.json > > > cc1: error: error parsing JSON data: expected ':'; got number > > > > > > $ ./xgcc -B. -S test.c -muser-provided-CPU=unsigned-3.json > > > cc1: warning: JSON tuning file does not contain version > > > information; > > > compatibility cannot be verified > > > cc1: error: key ‘tune_params.sve_width’ value 5000000000 is out > > > of > > > range for ‘uint’ type [0, 4294967295] > > > cc1: error: validation failed for the provided JSON data > > > > > > In particular it doesn't show location information within the > > > JSON > > > file. > > > > > > A further JSON input to GCC is being considered via patch > > > "fmv: Add -ftarget-clones-table option support" > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2026-February/708264.html > > > and that patch has similar issues with the diagnostics it emits > > > on > > > bad > > > input JSON. > > > > > > This patch kit: > > > * moves some support code out from libgdiagnostics and sarif- > > > replay > > > so > > > that it can be used with global_dc, > > > * uses that to introduce a new json-diagnostic.{cc,h} to make it > > > easy > > > to > > > emit JSON diagnostics with location information from within GCC > > > * updates aarch64's -muser-provided-CPU= implementation to > > > improve > > > the > > > error handling. > > > > > > With this patch, the above is improved to: > > > > > > $ ./xgcc -B. -S test.c -muser-provided-CPU=malformed.json > > > malformed.json:3:17: error: error parsing JSON data: expected > > > ':'; > > > got number > > > 3 | "sve_width" 128 > > > | ^~~ > > > > > > $ ./xgcc -B. -S test.c -muser-provided-CPU=unsigned-3.json > > > cc1: warning: JSON tuning file does not contain version > > > information; > > > compatibility cannot be verified > > > unsigned-3.json: In JSON value ‘/tune_params/sve_width’ > > > unsigned-3.json:3:18: error: key ‘tune_params.sve_width’ value > > > 5000000000 is out of range for ‘uint’ type [0, 4294967295] > > > 3 | "sve_width": 5000000000 > > > | ^~~~~~~~~~ > > > cc1: error: validation failed for the provided JSON data > > > > > > showing file:line:column of the problematic JSON, quoting and > > > underlining the pertinent part of the input, and showing the > > > JSON Pointer of the relevant value, if there is one. This data > > > is > > > also > > > now captured by SARIF and HTML diagnostic sinks. > > > > > > A similar approach could be adopted for the -ftarget-clones-table > > > patch to improve its diagnostics for bad input JSON. > > > > > > The option -muser-provided-CPU= is new in GCC 16, but apparently > > > is > > > intended purely for GCC developers. I'm not sure whether the fmv > > > json > > > patch is aimed at GCC 16 or GCC 17, but it appears to be aimed at > > > end-users. > > > > > > I'd like to push this to trunk now, but I appreciate that it's > > > non-trivial and not technically a fix of a regression, but it > > > does > > > add > > > UX polish. > > > > > > I can self-approve the diagnostics/json refactorings. > > > > > > aarch64 maintainers: are the aarch64 changes OK for trunk, either > > > in > > > stage 4 or next stage 1? > > > > > > Release managers: is this OK for stage 4, or should this wait > > > until > > > next > > > stage 1? > > > > > > Thanks > > > Dave > > > > > > David Malcolm (5): > > > diagnostics: use label_text for logical_location strings > > > diagnostics: split out physical_location_maker from > > > libgdiagnostics > > > json: split out replayer_location_map from libsarifreplay.cc > > > Add json-diagnostic.{cc,h} > > > aarch64: improve diagnostics for bogus JSON tuning inputs > > > [PR124094] > > > > > > gcc/Makefile.in | 3 +- > > > .../aarch64-generate-json-tuning-routines.py | 17 +- > > > .../aarch64-json-tunings-parser-generated.inc | 428 +++++++++--- > > > ---- > > > -- > > > .../aarch64/aarch64-json-tunings-parser.cc | 279 ++++++++---- > > > gcc/diagnostics/client-data-hooks.h | 53 +++ > > > gcc/diagnostics/context.cc | 5 +- > > > gcc/diagnostics/context.h | 4 +- > > > gcc/diagnostics/html-sink.cc | 11 +- > > > gcc/diagnostics/logical-locations.h | 6 +- > > > gcc/diagnostics/physical-location-maker.cc | 75 +++ > > > gcc/diagnostics/physical-location-maker.h | 60 +++ > > > gcc/diagnostics/sarif-sink.cc | 24 +- > > > gcc/diagnostics/selftest-logical-locations.cc | 18 +- > > > gcc/diagnostics/selftest-logical-locations.h | 6 +- > > > gcc/diagnostics/state-graphs-to-dot.cc | 15 +- > > > gcc/json-diagnostic.cc | 374 > > > +++++++++++++++ > > > gcc/json-diagnostic.h | 74 +++ > > > gcc/json-parsing.cc | 1 + > > > gcc/json-parsing.h | 24 + > > > gcc/libgdiagnostics.cc | 62 +-- > > > gcc/libsarifreplay.cc | 23 +- > > > .../aarch64/aarch64-json-tunings/boolean-2.c | 12 +- > > > .../aarch64-json-tunings/empty-brackets.c | 9 +- > > > .../aarch64/aarch64-json-tunings/enum-2.c | 19 +- > > > .../aarch64/aarch64-json-tunings/integer-2.c | 14 +- > > > .../aarch64/aarch64-json-tunings/integer-3.c | 13 +- > > > .../aarch64/aarch64-json-tunings/malformed.c | 11 + > > > .../aarch64-json-tunings/malformed.json | 5 + > > > .../aarch64/aarch64-json-tunings/string-2.c | 12 +- > > > .../aarch64-json-tunings/unidentified-key.c | 12 +- > > > .../aarch64/aarch64-json-tunings/unsigned-2.c | 10 +- > > > .../aarch64/aarch64-json-tunings/unsigned-3.c | 10 +- > > > gcc/tree-logical-location.cc | 26 +- > > > gcc/tree-logical-location.h | 6 +- > > > 34 files changed, 1275 insertions(+), 446 deletions(-) > > > create mode 100644 gcc/diagnostics/physical-location-maker.cc > > > create mode 100644 gcc/diagnostics/physical-location-maker.h > > > create mode 100644 gcc/json-diagnostic.cc > > > create mode 100644 gcc/json-diagnostic.h > > > create mode 100644 gcc/testsuite/gcc.target/aarch64/aarch64- > > > json- > > > tunings/malformed.c > > > create mode 100644 gcc/testsuite/gcc.target/aarch64/aarch64- > > > json- > > > tunings/malformed.json > > > > > >
