9 ms·

Usability Improvements in GCC 9

235 points by chx 8y ago

brian_herman__ 8y ago
Nice
lrsjng 8y ago
"With -fdiagnostics-format=json, the diagnostics are emitted as a big blob of JSON to stderr"
- codetrotter 8y ago
  I’ve previously been thinking about what would be the consequences of implementing a subset of Unix tools to work with a binary protocol. For example, tables would be output with type info and proper unambiguous delimiting of some sort. Unrelated to that I once wrote a program in the past several years ago as two distinct parts that communicated over a pair of Unix pipes; one part the GUI which embedded a web view and the other part which contained the program logic and which output HTML to stdout. The code was quite ugly, but anyway it did the job at the time. But the idea of outputting JSON is somewhat in between this two things. But the main takeaway here IMO is the idea about outputting a specific format as controlled by a flag. Of course other tools have done this too in the past. Consider a few Unix utilities reimplemented to work a bit tighter together in terms of how some data is represented, and using for example Cap’n Proto to serialize the data and piping that between them but also writing a library for destructively converting to plain text representation and then using some method or combination of methods for deciding when to use binary piping. For example, - A user-provided flag. Tiresome to type. - A user-provided environment variable. Problematic when mixing tools that implement serialization with pure plaintext tools. - The shell could be aware of which programs implement this serialization and invoke them with the flags or env vars corresponding to whether or not each program on each side of each pipe in a pipeline supports the serialization. Possibly the way to go. In this way one could incrementally rebuild the Unix tools to work this way without having to change everything at once and still being compatible with the universal interface of plaintext forever, since no-one wants nor can implement this in every Unix tool out there. Once you have a couple of tools support this then the possibility for new ways to interact with pipelines becomes available. I still love and will use the classic command-line. But in some situations the possibilities enabled by this would be very compelling indeed.
  - Longhanks 8y ago
    What you describe is PowerShell. It is available for most Linux and macOS.
    - codetrotter 8y ago
      I am aware that PowerShell is somewhat like this — in fact I started using PS before permanently switching to Linux back in 2009 — but I don’t enjoy PS. Some people like PS a lot I know and that’s great for them but for me it’s not something I am ever going to use again. I found my home with Unix those 10 years ago.
    - pantalaimon 8y ago
      IMHO what kills PowerShell is that it's so incredibly verbose.
      - svnpenn 8y ago
        Even with the built-in aliases?
    - int_19h 8y ago
      Not quite. PowerShell input and output are .NET objects - not just data, but also behavior. This requires both sides of the pipe to agree on the object model and the execution environment. JSON (or another pure data serialization format) is much better in that regard, because then you only need to agree on some basic data structures at the boundary.
  - emmelaich 8y ago
    I think csv (with a separator of your choice) would be ideal. It wouldn't require special tools but it could work with them. You could save the column headers, types and separator in extended attributes.
    - emmelaich 8y ago
      For extra points you could guarantee the structure of data by only allowing certain tools (selinux context maybe) that are trusted to write the files with the required structure. That would save a lot of repeated wasteful parsing and checking.
umvi 8y ago
Another major improvement to GCC9 is gcov - starting with GCC 9, gcov can spit out coverage results in JSON format as well as take multiple coverage files as arguments, spitting out all the results to stdout, 1 json object per line (this is huge). This will allow much of the code coverage calculation process to be done in parallel (i.e. much faster than is currently possible). This is because currently gcov writes everything out to files, which forces the wrapper to be single threaded lest one gcov process overwrite the output file of another. For fun, I wrote a parallelized GCC9 gcov wrapper in python that generates an LCOV coverage report that genhtml can consume. Unofficial/anecdotal bench marking shows incredible gains over lcov on my own personal projects (700ms vs. 90 seconds). I'm sure it could be improved even more. https://github.com/RPGillespie6/fastcov https://github.com/RPGillespie6/fastcov
- jcranmer 8y ago
  lcov can be really, really slow in how it handles its own file format. I ended up rewriting the genhtml stuff myself in Python (originally, it was to drive a treemap view, but extending it to handle the actual detailed coverage wasn't difficult), and then moved the "merge two files into one file" into Python as well for a >10x speedup. And Python is not known for its blazing speed. After that, I ended up shifting to tackling the generation of the initial data from .gcda and .gcno, which is where I discovered bugs in both lcov and gcov in the collection process. One bug is that gcov somehow manages to compute negative edge counts on certain cycles in the graph, and when that happens, it double-counts those cycles.
cryptonector 8y ago
> What is the optimizer doing? > ... Nice! Now, can we get warned about UB?
- bonzini 8y ago
  You can at run time with ubsan. At compile time it doesn't make sense, because undefined behavior is used for cases where the overwhelmingly common case you won't see undefined behavior. It'd have 99% false positives, pretty much by definition.
  - inetknght 8y ago
    Developers who have to work with actual responsibilities need to take those edge cases "you won't see" into account.
    - platinumrad 8y ago
      Correct me if I'm wrong, but I think you're misunderstanding what they're saying. They're not saying that undefined behavior can be ignored because it "probably won't happen" or something like that. They're saying that undefined behavior is everywhere in the C standard and that this fact is commonly exploited for the purposes of optimization. For example, signed integer overflow is undefined behavior which allows the compiler to avoid extra sign extensions when indexing in a loop. Would you want a warning to be emitted at compile time every single time you write "for (int i = 0...)"? I'm sure that would actually end up doing more harm than good as it would just condition people to ignore these warnings altogether. As the poster mentioned, ubsan will catch the cases you actually care about, albeit at runtime. It's also worth noting that GCC does try to warn at compile time about a lot of the undefined behavior that you do care about, such as strict aliasing violations when -Wall is enabled.
      - 0db532a0 8y ago
        Could you explain why in this hypothetical scenario a warning should be emitted for “for (int i = 0...)”?
favorited 8y ago
> One concern I’ve heard when changing how GCC prints diagnostics is that it might break someone’s script for parsing GCC output Honestly though, who would build a tool which depends on the (presumably undocumented) text output of another application, and then expect it not to break?
- michaelhoffman 8y ago
  I've built tools based on undocumented output of other applications because there was no documented way to get the information I needed. I don't expect that these won't break but it certainly doesn't make it less annoying when they do break.
  - favorited 8y ago
    Oh sure – the first few years of my tech career involved a lot of scraping data from the websites of enterprise tools because their APIs were either incomplete or nonexistent. It was annoying, but never unexpected.
- TomVDB 8y ago
  When that text output has remained consistent for decades(?) can you really consider it an undocumented format?
  - petronio 8y ago
    Yes. It's sort of like using undocumented API calls: even if it's been unchanged for a decade, if it's undocumented it can change at any time without the usual deprecation warnings and versioning considerations. Text output, particularly warnings and notes, isn't usually intentioned to be machine parseable and consistent in the first place, but rather is meant for humans to read and may be changed to be better read by humans at will.
    - TomVDB 8y ago
      Good thing then that it's not an undocumented API. :-) https://gcc.gnu.org/onlinedocs/gnat_ugn/Output-and-Error-Message-Control.html https://gcc.gnu.org/onlinedocs/gnat_ugn/Output-and-Error-Mes...
saagarjha 8y ago
Great! This directly addresses one of the reasons I use Clang most of the time, and it's great to see that the GCC realizing that error message quality-of-life is important. As an aside: $ gcc-9 -c cve-2014-1266.c -Wall cve-2014-1266.c: In function ‘SSLVerifySignedServerKeyExchange’: cve-2014-1266.c:629:2: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] 629 | if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) | ^~ cve-2014-1266.c:631:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 631 | goto fail; | ^~~~ this is a cute example ;)
- umvi 8y ago
  It saves us frequent users of C++/python from ourselves :P
- cardiffspaceman 8y ago
  If it weren't in a file named after a famous vuln, I would wonder what was on line 630, because the problem isn't obvious from just those two lines.
nemetroid 8y ago
My main issue with g++ compiler output is that for each coding error, I get a few lines of useful information, followed by a hundred "note:" lines detailing the finer details of increasingly improbable failed substitutions.
- jimbo1qaz 8y ago
  I wish gcc indented all the note lines, to indicate that they are sub-bullet-points of the actual error/warning.
- Zpalmtree 8y ago
  Clang by default shows only 20 error lines, or something like that, so you have to scroll up a ton less when compiling. I swapped to clang just for the improved error messages.
- mort96 8y ago
  I fixed that by making a small script which sends the output to `less` if it's over 30 lines: https://github.com/mortie/nixConf/blob/master/bin/msoak https://github.com/mortie/nixConf/blob/master/bin/msoak With that, `msoak make` will show the first lines first, and let you scroll down to see the rest. (Simply doing `make | less` isn't enough, because you need to fool the program into thinking it's sending output to a TTY for nice colors.)
iheartpotatoes 8y ago
I would be really interested to know what kind of unit testing was done to prove that a feature like this won't break anything. I see that he left the original messages and added more guidance, so it would be possible to regress against GCC8. But the addition of the new guidance must require a certain degree of code partitioning and hand-inspection, given how complex GCC is under the hood.
argd678 8y ago
I’ve been using Terraform a lot lately and aside from no debugger and even line numbers on errors, I wish it had used a real language and had usable errors like this. Great too see, it’s the human computers that are the most expensive to run so you don’t want to waste their time.

235 points by chx 8y ago

brian_herman__ 8y ago

Nice

lrsjng 8y ago

"With -fdiagnostics-format=json, the diagnostics are emitted as a big blob of JSON to stderr"

codetrotter 8y ago
I’ve previously been thinking about what would be the consequences of implementing a subset of Unix tools to work with a binary protocol. For example, tables would be output with type info and proper unambiguous delimiting of some sort. Unrelated to that I once wrote a program in the past several years ago as two distinct parts that communicated over a pair of Unix pipes; one part the GUI which embedded a web view and the other part which contained the program logic and which output HTML to stdout. The code was quite ugly, but anyway it did the job at the time. But the idea of outputting JSON is somewhat in between this two things. But the main takeaway here IMO is the idea about outputting a specific format as controlled by a flag. Of course other tools have done this too in the past. Consider a few Unix utilities reimplemented to work a bit tighter together in terms of how some data is represented, and using for example Cap’n Proto to serialize the data and piping that between them but also writing a library for destructively converting to plain text representation and then using some method or combination of methods for deciding when to use binary piping. For example, - A user-provided flag. Tiresome to type. - A user-provided environment variable. Problematic when mixing tools that implement serialization with pure plaintext tools. - The shell could be aware of which programs implement this serialization and invoke them with the flags or env vars corresponding to whether or not each program on each side of each pipe in a pipeline supports the serialization. Possibly the way to go. In this way one could incrementally rebuild the Unix tools to work this way without having to change everything at once and still being compatible with the universal interface of plaintext forever, since no-one wants nor can implement this in every Unix tool out there. Once you have a couple of tools support this then the possibility for new ways to interact with pipelines becomes available. I still love and will use the classic command-line. But in some situations the possibilities enabled by this would be very compelling indeed.
- Longhanks 8y ago
  What you describe is PowerShell. It is available for most Linux and macOS.
  - codetrotter 8y ago
    I am aware that PowerShell is somewhat like this — in fact I started using PS before permanently switching to Linux back in 2009 — but I don’t enjoy PS. Some people like PS a lot I know and that’s great for them but for me it’s not something I am ever going to use again. I found my home with Unix those 10 years ago.
  - pantalaimon 8y ago
    IMHO what kills PowerShell is that it's so incredibly verbose.
    - svnpenn 8y ago
      Even with the built-in aliases?
  - int_19h 8y ago
    Not quite. PowerShell input and output are .NET objects - not just data, but also behavior. This requires both sides of the pipe to agree on the object model and the execution environment. JSON (or another pure data serialization format) is much better in that regard, because then you only need to agree on some basic data structures at the boundary.
- emmelaich 8y ago
  I think csv (with a separator of your choice) would be ideal. It wouldn't require special tools but it could work with them. You could save the column headers, types and separator in extended attributes.
  - emmelaich 8y ago
    For extra points you could guarantee the structure of data by only allowing certain tools (selinux context maybe) that are trusted to write the files with the required structure. That would save a lot of repeated wasteful parsing and checking.

umvi 8y ago

Another major improvement to GCC9 is gcov - starting with GCC 9, gcov can spit out coverage results in JSON format as well as take multiple coverage files as arguments, spitting out all the results to stdout, 1 json object per line (this is huge). This will allow much of the code coverage calculation process to be done in parallel (i.e. much faster than is currently possible). This is because currently gcov writes everything out to files, which forces the wrapper to be single threaded lest one gcov process overwrite the output file of another. For fun, I wrote a parallelized GCC9 gcov wrapper in python that generates an LCOV coverage report that genhtml can consume. Unofficial/anecdotal bench marking shows incredible gains over lcov on my own personal projects (700ms vs. 90 seconds). I'm sure it could be improved even more. https://github.com/RPGillespie6/fastcov https://github.com/RPGillespie6/fastcov

jcranmer 8y ago
lcov can be really, really slow in how it handles its own file format. I ended up rewriting the genhtml stuff myself in Python (originally, it was to drive a treemap view, but extending it to handle the actual detailed coverage wasn't difficult), and then moved the "merge two files into one file" into Python as well for a >10x speedup. And Python is not known for its blazing speed. After that, I ended up shifting to tackling the generation of the initial data from .gcda and .gcno, which is where I discovered bugs in both lcov and gcov in the collection process. One bug is that gcov somehow manages to compute negative edge counts on certain cycles in the graph, and when that happens, it double-counts those cycles.

cryptonector 8y ago

> What is the optimizer doing? > ... Nice! Now, can we get warned about UB?

bonzini 8y ago
You can at run time with ubsan. At compile time it doesn't make sense, because undefined behavior is used for cases where the overwhelmingly common case you won't see undefined behavior. It'd have 99% false positives, pretty much by definition.
- inetknght 8y ago
  Developers who have to work with actual responsibilities need to take those edge cases "you won't see" into account.
  - platinumrad 8y ago
    Correct me if I'm wrong, but I think you're misunderstanding what they're saying. They're not saying that undefined behavior can be ignored because it "probably won't happen" or something like that. They're saying that undefined behavior is everywhere in the C standard and that this fact is commonly exploited for the purposes of optimization. For example, signed integer overflow is undefined behavior which allows the compiler to avoid extra sign extensions when indexing in a loop. Would you want a warning to be emitted at compile time every single time you write "for (int i = 0...)"? I'm sure that would actually end up doing more harm than good as it would just condition people to ignore these warnings altogether. As the poster mentioned, ubsan will catch the cases you actually care about, albeit at runtime. It's also worth noting that GCC does try to warn at compile time about a lot of the undefined behavior that you do care about, such as strict aliasing violations when -Wall is enabled.
    - 0db532a0 8y ago
      Could you explain why in this hypothetical scenario a warning should be emitted for “for (int i = 0...)”?

favorited 8y ago

> One concern I’ve heard when changing how GCC prints diagnostics is that it might break someone’s script for parsing GCC output Honestly though, who would build a tool which depends on the (presumably undocumented) text output of another application, and then expect it not to break?

michaelhoffman 8y ago
I've built tools based on undocumented output of other applications because there was no documented way to get the information I needed. I don't expect that these won't break but it certainly doesn't make it less annoying when they do break.
- favorited 8y ago
  Oh sure – the first few years of my tech career involved a lot of scraping data from the websites of enterprise tools because their APIs were either incomplete or nonexistent. It was annoying, but never unexpected.
TomVDB 8y ago
When that text output has remained consistent for decades(?) can you really consider it an undocumented format?
- petronio 8y ago
  Yes. It's sort of like using undocumented API calls: even if it's been unchanged for a decade, if it's undocumented it can change at any time without the usual deprecation warnings and versioning considerations. Text output, particularly warnings and notes, isn't usually intentioned to be machine parseable and consistent in the first place, but rather is meant for humans to read and may be changed to be better read by humans at will.
  - TomVDB 8y ago
    Good thing then that it's not an undocumented API. :-) https://gcc.gnu.org/onlinedocs/gnat_ugn/Output-and-Error-Message-Control.html https://gcc.gnu.org/onlinedocs/gnat_ugn/Output-and-Error-Mes...

saagarjha 8y ago

Great! This directly addresses one of the reasons I use Clang most of the time, and it's great to see that the GCC realizing that error message quality-of-life is important. As an aside: $ gcc-9 -c cve-2014-1266.c -Wall cve-2014-1266.c: In function ‘SSLVerifySignedServerKeyExchange’: cve-2014-1266.c:629:2: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] 629 | if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) | ^~ cve-2014-1266.c:631:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 631 | goto fail; | ^~~~ this is a cute example ;)

umvi 8y ago
It saves us frequent users of C++/python from ourselves :P
cardiffspaceman 8y ago
If it weren't in a file named after a famous vuln, I would wonder what was on line 630, because the problem isn't obvious from just those two lines.

nemetroid 8y ago

My main issue with g++ compiler output is that for each coding error, I get a few lines of useful information, followed by a hundred "note:" lines detailing the finer details of increasingly improbable failed substitutions.

jimbo1qaz 8y ago
I wish gcc indented all the note lines, to indicate that they are sub-bullet-points of the actual error/warning.
Zpalmtree 8y ago
Clang by default shows only 20 error lines, or something like that, so you have to scroll up a ton less when compiling. I swapped to clang just for the improved error messages.
mort96 8y ago
I fixed that by making a small script which sends the output to `less` if it's over 30 lines: https://github.com/mortie/nixConf/blob/master/bin/msoak https://github.com/mortie/nixConf/blob/master/bin/msoak With that, `msoak make` will show the first lines first, and let you scroll down to see the rest. (Simply doing `make | less` isn't enough, because you need to fool the program into thinking it's sending output to a TTY for nice colors.)

iheartpotatoes 8y ago

I would be really interested to know what kind of unit testing was done to prove that a feature like this won't break anything. I see that he left the original messages and added more guidance, so it would be possible to regress against GCC8. But the addition of the new guidance must require a certain degree of code partitioning and hand-inspection, given how complex GCC is under the hood.

argd678 8y ago

I’ve been using Terraform a lot lately and aside from no debugger and even line numbers on errors, I wish it had used a real language and had usable errors like this. Great too see, it’s the human computers that are the most expensive to run so you don’t want to waste their time.