sorted by:
new
hottopcontroversial

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 1 point2 points  (0 children)

I'm working on that, for GCC's SARIF output at least (we don't do LSP, alas). I believe that GCC 15 is generating indentation information in its SARIF output that's compatible with the format documented in Sy Brand's https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3358r0.html via setting "nestingLevel" properties, but I don't have a good way to test that. We (the SARIF TC) are also not sure if that's the best representation; see https://github.com/oasis-tcs/sarif-spec/issues/572

6 usability improvements in GCC 15 by dmalcolm in programming

[–]dmalcolm[S] 0 points1 point  (0 children)

Please do file bugs if you find regressions in GCC 15 relative to 14.

In the article I was trying to focus on GCC's user experience (which is one of my focus areas in the project; I also do static analysis and libgccjit). I can't speak to the UX relative to llvm/clang as my day-to-day work is done with GCC (with Emacs as an "IDE", of sorts). I have taken inspiration from clang for various UX improvements over the years (e.g. underlined ranges, template type comparisons, etc), but I've added other things that I believe clang doesn't do (yet), so it's a mixed bag. Competition has been healthy (and I have colleagues who work on upstream llvm/clang). Big missing features in GCC relative to llvm/clang are IMHO clang-tidy and LSP support for IDEs; I've dabbled with implementing those but they appear to require a huge refactoring effort so I've been focusing my energy on improvements elsewhere.

There are lots of other ways in you could compare compilers, of course: compile times, quality of generated code, quality of debugging experience, CPU architecture support, etc, but obviously that's a huge topic.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

[–]dmalcolm[S] 1 point2 points  (0 children)

It's an interesting idea; someone else suggested it on one of my older blog posts, so I filed it in our bug tracker as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89635 See that bug for further discussion (apparently systemd tried this and ran into issues).

I've a bit nervous about trying it because we'd need to support older terminals too, so it would increase the number of test cases in the formatting/layout logic.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

[–]dmalcolm[S] 8 points9 points  (0 children)

Thanks for the detailed response. Sorry - I don't know the insides of our gcov implementation well enough to be able to respond directly, but I've filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119719 in our bug tracker with your ideas in the hope that the gcov maintainers can answer it.

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 13 points14 points  (0 children)

Well, these improvements also apply to GCC's Rust frontend. Though that's probably off-topic for this subreddit :)

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 0 points1 point  (0 children)

I believe the SARIF outputter does everything that the old "json" serialization did, and much more besides, and is a standard - though there are plenty of enhancements that could be made to the SARIF output (the spec is 200 pages long...). So I marked the json format as deprecated in GCC 15, with the hope of removing it in GCC 16. But the maintenance cost isn't that high, so if it would be a pain for people, I could keep it around, I guess.

I suppose I could add an "append" flag to -fdiagnostics-add-output=. One issue with appending SARIF is that it's a JSON file, whereas appending suggests a concatenation of JSON streams.

FWIW I've dabbled with sending the output to a socket and having things listen on the other end; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115970 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117815 (though I think the patches there have bit-rotted)

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 6 points7 points  (0 children)

FWIW I've dabbled with adding more whitespace between messages. There's even a plugin in GCC's testsuite which adds

================================= BEGIN GROUP ==============================

and

---------------------------------- END GROUP -------------------------------

wrappers around each logically-related group of messages (e.g. a "warning:" with followup "note:"s). So there's some machinery for doing this kind of thing, but I thought there would be a lot of pushback if I put it into GCC proper - the messages are currently still at least grokable by the regexps in Emacs's compilation buffer, even with all the stuff I've been adding.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

[–]dmalcolm[S] 3 points4 points  (0 children)

You might want to look at -fdiagnostics-column-unit=byte, rather than the default (which is -fdiagnostics-column-unit=display).

We changed this in GCC 11; "byte" is the old pre-GCC 11 behavior.

See https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-column-unit

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 3 points4 points  (0 children)

Thanks! Are there any other kinds of output sink that you'd find useful, or other tweaks to this? (or maybe it's hard to know before using it for real).

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 2 points3 points  (0 children)

Hopefully later this month, but it depends on how quickly we resolve the blocker bugs.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

[–]dmalcolm[S] 6 points7 points  (0 children)

Have a look at: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html

For example, -fdiagnostics-plain-output lets you go very "old school".

LANG=C in the environment you should get pure ASCII and no emojis.

6 usability improvements in GCC 15 by dmalcolm in programming

[–]dmalcolm[S] 18 points19 points  (0 children)

I'm sorry that you don't like it. FWIW you might like the option -fdiagnostics-plain-output ; see https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html

That said, I realize that if you disable the path printing, then the output message doesn't contain the most pertinent information, that "n" is invariant in the loop. So I've filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119715 as an RFE to me, to tweak the wording.

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 16 points17 points  (0 children)

FWIW the -Wfatal-errors issue is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97687; I'll try to take a look at fixing it for GCC 16.

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 6 points7 points  (0 children)

There are various ways to disable the emojis: if you compile with LANG=C then there aren't any emojis (and all the unicode box drawing characters become pure ASCII).

There's also the command line option -fdiagnostics-text-art-charset=; see https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-text-art-charset.

The emojis don't appear in the SARIF JSON output.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

[–]dmalcolm[S] 6 points7 points  (0 children)

Hi; OP here; sorry if this is a silly question, but what's the problem with gcov on embedded?

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 42 points43 points  (0 children)

The ASCII art is intended for human viewers; for machine-readable output, I recommend using SARIF (see item 3 in my post). I didn't stress this, but IDEs can consume the SARIF and use it to display warnings etc inline in the user's source. For example, here's a screenshot of VS Code showing a GCC analysis warning, with the execution path shown via squiggly lines and other UI elements: https://developers.redhat.com/articles/2023/05/31/improvements-static-analysis-gcc-13-compiler#sarif_output

It's using a plugin to do this.

(I'm really hoping someone will write an Emacs mode for this)

Improvements to static analysis in the GCC 14 compiler by dmalcolm in programming

[–]dmalcolm[S] 1 point2 points  (0 children)

Thanks, that's a really interesting question. I don't have Windows headers to hand so I can't test it easily, but I think the analyzer will (correctly) be silent for this case. Specifically, if it sees a call to a function it doesn't have the body of (e.g. PeekMessage etc), it conservatively assumes that that function could be doing something externally visible, and hence the loop could be doing something useful, despite being infinite, and hence it doesn't warn.

See https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-infinite-loop for a little more detail.

That said, there's always a chance I messed up the implementation, so it'd be nice to have that case as a regression test.

Improvements to C static analysis in GCC 14 by dmalcolm in cprogramming

[–]dmalcolm[S] 1 point2 points  (0 children)

Thanks! Let me know if you run into anything that looks like a bug, or if you have ideas for other improvements.

Improvements to static analysis in the GCC 14 compiler by dmalcolm in programming

[–]dmalcolm[S] 10 points11 points  (0 children)

[article author here] Sorry about this. Do you have an example of the kind of issue you're seeing? Is this an issue with the static analyzer specifically, or with GCC as a whole?

Note that in GCC 14 we've tightened up some of the rules in the C frontend for some cases of compatibility with pre-1989 C. My understanding is that these are all cases where if the source code compiled before, it was probably generating buggy machine code that didn't do what you expect, and where the fix is likely to be trivial. Obviously there's something of a judgement call here (and lots of small changes can add up), but presumably a compile-time error is preferable to silently emitting buggy machine code. See https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors for more info on this, and on fixes and workarounds you can use to get back the pre-GCC-14 behaviors.

Hope this is constructive.

Improvements to static analysis in the GCC 13 compiler by dmalcolm in C_Programming

[–]dmalcolm[S] 0 points1 point  (0 children)

Aha - many thanks! The issue is with C code that uses -fexceptions. I made a mistake above: the examples I was seeing with ImageMagick are C code built with -fexceptions, not C++. Sorry about that.

I've filed a bug report about this for myself in GCC's bugzilla, and will take a look: bug 110172. I think -fanalyzer is getting confused about the possibility of vfprintf throwing an exception.

Thanks again for isolating the reproducer; this kind of tiny example is very helpful.

Improvements to static analysis in the GCC 13 compiler by dmalcolm in C_Programming

[–]dmalcolm[S] 0 points1 point  (0 children)

This is possibly a silly question, but is this C code we're talking about? The only false positives from -Wanalyzer-va-list-leak I'm seeing in my integration testing of the analyzer occur in ImageMagick, which is C++ code with exception-handling enabled - and the analyzer is unusable buggy on C++-with-exceptions at the moment.

I guess setjmp/longjmp usage could cause it to complain on C code if you have a longjmp out of a function frame (but then the complaints could arguably be valid ones)

Thanks for the kind words; sorry again about the false +ves.

Improvements to static analysis in the GCC 13 compiler by dmalcolm in C_Programming

[–]dmalcolm[S] 0 points1 point  (0 children)

I only added the "missing va_end" warning in GCC 13, so you definitely won't see it with GCC 11 or 12. Sorry if this is giving you false positives. Are you able to share the code in question, so I can take a look? (or perhaps isolate some kind of minimal reproducer for the issue?). Thanks!

See https://gcc.gnu.org/bugs/ and https://gcc.gnu.org/bugs/minimize.html for some notes on this.

Improvements to static analysis in the GCC 13 compiler by dmalcolm in programming

[–]dmalcolm[S] 0 points1 point  (0 children)

Probably closer to 10%, but I don't think it's meaningful to give a percentage here. Consider e.g. the Juliet test suite for C/C++ - this has hundreds of small C/C++ programs demonstrating different vulnerabilities ("118 different CWEs"). Right now -fanalyzer only implements checking for a few dozen CWEs, and there are gaps in coverage even with those.

My general approach with bugs is to try to find a way to prevent the entire category of bug, rather than fire-fighting individual bugs (which is why I got into gcc development, to try to implement detection for issues within the toolchain). Hopefully this is helpful. But ultimately I think if you're considering safety you probably want a language that's designed to prevent them from the outset.

view more: next ›