|
|
Log in / Subscribe / Register

Malcolm: 6 usability improvements in GCC 15

[Posted April 10, 2025 by jake]

Over on the Red Hat Developer site, David Malcolm has an article about improvements in GCC 15, specifically focusing on the diagnostic information that the compiler emits. This includes ASCII art with a "⚠️" warning emoji to display the execution path when it detects a problem (like an infinite loop in one of his examples), better C++ template errors, machine-readable diagnostics using Static Analysis Results Interchange Format (SARIF), better messages regarding C23 compatibility since that is the default C version for GCC 15, and more. Since the changes are focused on messages, there is the inevitable color-scheme update as well:
GCC will use color when emitting its text messages on stderr at a suitably modern terminal, using a few colors that seem to work well in a number of different terminal themes—but the exact rules for choosing which color to use for each aspect of the output have been rather arbitrary.

For GCC 15, I've gone through C and C++'s errors, looking for places where two different things in the source are being contrasted, such as type mismatches. These diagnostics now use color to visually highlight and distinguish the differences.


to post comments

Always a treat

Posted Apr 11, 2025 5:00 UTC (Fri) by krakensden (guest, #72039) [Link]

I love these blog posts, always great to hear about people making sure that even C and C++ developers can have nice things.

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 11, 2025 9:20 UTC (Fri) by jengelh (subscriber, #33263) [Link] (9 responses)

>ASCII art with a "⚠️" warning emoji

So not only is it no longer ASCII, but now a bunch of people will see a bunch of � or ▯.

I also notice that most terminals don't get the width of ⚠️ right, which is a shame considering doublewidth CJK has worked for over a decade.

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 11, 2025 11:47 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (2 responses)

The blog post says it will render such things on terminals that are compatible. I don't know if it will only check LANG or anything else. Anyway, /!\ has always been fine to me!

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 11, 2025 15:54 UTC (Fri) by eru (subscriber, #2753) [Link] (1 responses)

The capability to display unicode does not depend just on the terminal type, but also on the fonts that are available. don't see how GCC could query that.

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 11, 2025 16:28 UTC (Fri) by jwakely (subscriber, #60262) [Link]

And so there are options which disable all the fancy output.

-fdiagnostics-plain-output implies -fdiagnostics-text-art-charset=none but there are other values for -fdiagnostics-text-art-charset too, none, ascii, unicode, or emoji.

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 13, 2025 8:17 UTC (Sun) by pm215 (subscriber, #98099) [Link] (5 responses)

The "GCC should output only pure ASCII by default" battle was lost over a decade ago -- it has used fancy unicode quotes in error and warning messages rather than the plain ASCII ones for at least that long...

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 14, 2025 8:41 UTC (Mon) by maxfragg (subscriber, #122266) [Link]

this, just that the unicode was more subtle, so less people noticed it and couldn't complain about it, because reality is:
unicode just works and people should stop being afraid of it.

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 14, 2025 8:50 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

and the unicode quotes break copy-pasting.

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 17, 2025 20:47 UTC (Thu) by jwakely (subscriber, #60262) [Link]

Break it how?

N.B. with LANG=C you get plain ASCII quotes.

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 14, 2025 9:17 UTC (Mon) by excors (subscriber, #95769) [Link] (1 responses)

I was curious about the dates so I checked the release notes: Unicode quotation marks were introduced by GCC 4.0, in 2005. And in a more visible deviation from pure ASCII, coloured diagnostic messages were introduced by GCC 4.9 in 2014. (Clang used colour since at least 2009, maybe earlier.)

Also the emojis are not new: GCC 14 (2024) used the Warning Sign when illustrating buffer overflows, as well as some Unicode box-drawing symbols (https://developers.redhat.com/articles/2024/04/03/improve...)

I want `export LC_CTYPE=C.UTF-8@nosmp`

Posted Apr 14, 2025 23:46 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

I agree with you overall (Unicode is not new), but I'd just like to clarify that color is not a Unicode thing. It is entirely within the domain of terminfo(5) and its associated swamp of horrifying complexity. So when it breaks, please do not blame the Unicode consortium, because they had nothing to do with it.

Emojis is not what you want

Posted Apr 11, 2025 15:34 UTC (Fri) by adobriyan (guest, #30858) [Link] (1 responses)

I suggest to not stop, steal arbitrary code execution at compile time from Jai so that compiler can communicate with programmer in spoken languages. Those "error: "s and "warning: "s always felt robotic.

https://youtu.be/HcXu4_K1tMQ?t=245

Emojis is not what you want

Posted Apr 11, 2025 17:56 UTC (Fri) by tuna (guest, #44480) [Link]

How can I use/download the Jai compiler?

Keep it simple

Posted Apr 12, 2025 8:57 UTC (Sat) by simlo (guest, #10866) [Link] (5 responses)

Compilers should stick to ASCII. Everything else is terrible mess.

The good thing about open source is that you can just remove it. In theory. In practice, we are victims of the whatever a project decides. In theory, we could all maintain our small forks, but we all know that in practice it doesn't work at all. DVCS made it a little closer, but fundamentally it is just too hard to forever merge from a upstream branch into your own.

Keep it simple

Posted Apr 12, 2025 9:04 UTC (Sat) by oldtomas (guest, #72579) [Link] (4 responses)

I don't like those emojis either. But then, as jwakely writes above, there are options to switch things off, you don't even need to hack the source.

So all is well, I suppose. At least I'm fine with that, and glad that people who do like emojis can also have their fun.

Keep it simple

Posted Apr 12, 2025 9:21 UTC (Sat) by kleptog (subscriber, #1183) [Link] (3 responses)

I used to also not be a fan of emojis in terminals but I've seen people use them appropriately for things like ticks/crosses/warning symbols/etc. And I've come round to the idea that the fact that those symbols weren't part of standard ASCII is more an accident of history than anything else.

And honestly, it's 2025. The idea that we need to limit ourselves to 128 characters seems a bit outdated these days.

Keep it simple

Posted Apr 13, 2025 8:33 UTC (Sun) by cpitrat (subscriber, #116459) [Link] (2 responses)

And having these emojis used by GCC will be a strong incentive to include them in all the fonts that are used in terminals (so typically all fixed-width fonts)

Keep it simple

Posted Apr 15, 2025 0:15 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

It's not just that. Emoji are useful as a forcing function, because they often make use of complicated or "weird" corners of the Unicode spec. Many emoji sequences are defined as multiple code points stuck together with ZWJ characters (U+200D), and in order to render them, it's not just a matter of installing fonts. Your rendering stack needs to understand at least all of the following:

* A combining character sequence may consist of more than two characters.
* A combining character sequence may consist entirely of characters that are also valid by themselves (ZWJ has other uses that are not gluing emoji together).
* Finding the end of a combining character sequence requires lookahead (e.g. some of the family emoji are prefixes of other, longer family emoji).
* You can't (always) render combining characters on top of each other and call it a day. You may need to look up a different grapheme altogether (e.g. you can't render the "male" or "female" symbols on top of a gender-neutral face to make a male or female emoji).

There are quite a few scripts that need (some of) these features just to display regular text correctly, but if emoji didn't exist, then some vendors might not bother to implement them (these requirements are relatively uncommon in "western" scripts, for various interpretations of "western"), or if we're charitable, they might not realize that these corner cases are even possible.

Keep it simple

Posted Apr 17, 2025 9:49 UTC (Thu) by jch (guest, #51929) [Link]

> having these emojis used by GCC will be a strong incentive to include them in all the fonts that are used in terminalsmbo

There's no reason why the emojis should be included in every font.

The rendering stack should be able to combine symbols from multiple fonts, and the terminal emulator should be able to detect that it is using a fixed width font and scale the emoji to fit the character grid. That's actually a very old technique, and one that was used with East-Asian fonts since at least the 1980s.

(I personally implemented that for PostScript back in 1999 or 2000, https://www.irif.fr/~jch/software/cedilla/README.pdf, but the technique didn't catch on, people continued implementing the brute-force solution. I guess there's more money in large fonts.)

Fufu

Posted Apr 12, 2025 9:48 UTC (Sat) by faberman (guest, #158718) [Link]

The only improvement I see is that the CWD can now be output in the diagnostics. There are still a few things missing that make gcc diagnostics really usable in larger build systems.

Emoji output? Seriously? And in gcc 16 I can swipe right to auto-apply the suggested fix? :)

C23.... really?

Posted Apr 17, 2025 7:59 UTC (Thu) by cliddell (subscriber, #6085) [Link]

I'm surprised so much focus is on the (only slightly) further use of Unicode in the gcc15 diagnostics.

And nothing about switching the DEFAULT C language version to C23, when gcc14 doesn't even have a full implementation of that language version as an option.

I try to be less conservative than C developers are often reputed to be, but it seems premature to me to switch the default to a version that hasn't even been available as a option for a previous release.

I won't enjoy this

Posted May 20, 2025 2:33 UTC (Tue) by dagobayard (subscriber, #174025) [Link] (4 responses)

I hope it respects USE_EMOJI at the very least, and I hope for something like LS_COLORS as well.
--
Ian

I won't enjoy this

Posted May 20, 2025 6:19 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

`LS_COLORS` seems unrelated. Do you mean `NO_COLOR`[1]? `USE_EMOJI` doesn't seem to have a website like that; I only see discussion on `pipx`. I think requesting `GCC_USE_EMOJI` and `USE_EMOJI` makes sense as an issue.

[1] https://no-color.org/

I won't enjoy this

Posted May 20, 2025 17:56 UTC (Tue) by kleptog (subscriber, #1183) [Link] (2 responses)

Wouldn't it be called USE_UTF8? Because it's not emoji per se. If you can't handle those you probably can't handle anything outside of ASCII.

I won't enjoy this

Posted May 20, 2025 18:21 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

My terminal has fonts for most popular language scripts in use today (e.g., I can see that I get Thai, Arabic, and Japanese spam) but emoji is a very different story with a series of boxes that mutt and tmux disagree on the width of so sometimes things "leak" across lines in the mailbox view when somethings gets too emoji-happy. I think it's different both because terminal fonts with emoji support are far behind and tooling support with newer emoji metadata is a mixed bag.

I won't enjoy this

Posted May 21, 2025 2:38 UTC (Wed) by dagobayard (subscriber, #174025) [Link]

It's not that I "can't handle" them -- they display correctly in my terminal app when enabled. I just find them distracting and even insulting. USE_EMOJI is respected by opam, the Ocaml package manager, at least, in addition to pipx. I think two is enough to make it a de facto standard. I haven't heard of NO_COLOR, but yes, that would be a direct and better way to disable colorization across programs than a specialized variable per program.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds