FWIW I implemented SARIF output in GCC 13, which gives a machine-readable interchange format for the errors. It's viewable by e.g. VS Code (via a plugin). Hopefully that makes it easier to grok the messages.
You can see an example of the output here: https://godbolt.org/z/aan6Kfxds (that's the first example from the article, with -fdiagnostics-format=sarif-stderr added to the command-line options)
That doesn't cover the diagrams though (which I currently serialize in SARIF form by making a placeholder Markdown text containing "code" containing the diagram).
I experimented with SVG output for the diagrams, but didn't get this in good enough shape for GCC 14.
I've got a few ideas for more general UX improvements with how we do diagnostics, which I'll try in GCC 15 once we're finished focusing on GCC 14 bugfixing.
FWIW I implemented SARIF output in GCC 13 which is viewable by e.g. VS Code (via a plugin) - though the ASCII art isn't.
You can see an example of the output here:
https://godbolt.org/z/aan6Kfxds
(that's the first example from the article, with -fdiagnostics-format=sarif-stderr added to the command-line options)
I experimented with SVG output for the diagrams, but didn't get this in good enough shape for GCC 14.
Indeed, dealing with multiple configurations with lots of dependencies is hard.
I looked in the option metadata for our C/C++ frontends and
-Wduplicated-branches
isn't flagged as RejectNegative, so
-Wno-duplicated-branches
ought to work; I think you ought to be able to set that on a pragma. Does that help?
libgccjit is in maintenance mode: I believe it has everything you need if you (or someone else) wants to implement a JIT for GNU Octave (or for any other interpreter)- I just don't want to be the person to do that, as I have enough on my hands with GCC work; I can't become an Octave maintainer too...
I'm more than willing to help answer questions on it if you or someone else from the GNU Octave community wants to do it (are you doing Summer of Code this year?)
Are there other cases where idiomatic C++ might lead to such an indirect suggestion being appropriate for accessing the field?
(std::tuple, I suppose, but I'm not sure how often that would arise in practice...)
i.e. that's one 700 line test source file, expressing most of the test coverage for one feature.
I realize now that the post should have had an example of what such a test case has; see the "dg-warning" directives in that file.
So that's one "single file" test case. That said, I had to put some of the other test cases for that feature into different test files: some of them interact with the preprocessor in "interesting" ways, so it was simplest to split them out.
However, when a test starts failing, it's handy if the failing test is small (especially when stepping through the latter in the debugger...).
So in our testing we have a mix of both big test files covering a lot of material, and small test files, covering very specific corner cases.
Another aspect of granularity is how long the testsuite takes to run: each test source file in the DejaGnu suite involves exec-ing the compiler, which adds a fixed amount of overhead. It parallelizes well, but it's still advantageous to stuff more testing into fewer files (with the obvious tradeoff w.r.t. debugability if something starts failing). This was another reason for adding the unit-testing suite: this part is all done in-process, and so these ~30,000 tests run in less than a second.
It seems to be working again. Sorry about the snafu. I've been exchanging emails with the team on the hosting side, but I don't yet have info on what happened.
Yes: memory management in the compiler is interesting. There's a complicated graph of pointer references. Most of the time the compiler is building something relatively small, so we don't need to bother cleaning up, we just exit without freeing it all (for speed). But when e.g. building with Link Time Optimization, we can use large amounts of RAM, so a garbage-collection can be needed.
Sorry about that. I've filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588 about this and I'll try to get it fixed before GCC 14 releases properly (i.e. for GCC 14.1)