WingNews logo WingNews GitHub [2]

dmalcolm's comments

dmalcolm | 1 year ago | on: GCC 14 Boasts Nice ASCII Art for Visualizing Buffer Overflows

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.

dmalcolm | 1 year ago | on: Improvements to static analysis in GCC 14

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.

dmalcolm | 8 years ago | on: Usability improvements in GCC 8

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?

dmalcolm | 8 years ago | on: Usability improvements in GCC 8

Hi Jordi!

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?)

dmalcolm | 8 years ago | on: Usability improvements in GCC 8

[author of the blog post here]

Sadly, gcc 8 isn't smart enough to do that yet; I only implemented it for simple "return name_of_field;" accessors.

But it's an interesting idea, which I've filed as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895 - thanks.

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...)

dmalcolm | 9 years ago | on: Testing GCC

[author of the post]

Thanks for the links; a lot of interesting material in there.

FWIW, DejaGnu gives some flexibility over how granular the test files can be. For example, here's part of the test case for the -Wmisleading-indentation warning I added in gcc 6: https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/...

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.

dmalcolm | 9 years ago | on: Testing GCC

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.

dmalcolm | 9 years ago | on: Testing GCC

[author of the post here]

Thanks; am chasing it up at my end

dmalcolm | 9 years ago | on: Testing GCC

[author of the post here] Correct: loading the IR dumps back in is new.

dmalcolm | 9 years ago | on: Testing GCC

[author of the post here]

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.

page 1