Live data from Hacker News

Usability Improvements in GCC 15

developers.redhat.com

71–80 of 231 posts

Re: Usability Improvements in GCC 15

#71
post #18
post #13

Earlier quoted context omitted.

Embedded compiler vendors and UNIXes want a possibly slightly patched C or C++ compiler, maybe with an extra back-end bolted on. I'm talking about use-cases like Rust and Zig and Swift, projects which want a solid optimizing back-end but their own front-end and tooling.

And FOSS folks most likely would like to enjoy those patches as well on their installations.

I haven't advocated for re-licensing GCC to be permissively licensed. And patching GCC is necessarily going to be much easier for vendors than to build a new C front-end which generates GCC IR. So I'm not sure what difference you think what I'm proposing would make with regard to your concerns.

Re: Usability Improvements in GCC 15

#72
post #47

Earlier quoted context omitted.

I believe GCC still wins by far on support for weird CPUs and embedded systems.

With LLVM I doubt this will remain true. LLVM makes custom code generation far too easy for GCC to remain viable imo.

I don't have much experience with writing a custom gcc backend, but my experience with LLVM is that its model ends up being a somewhat poor fit for smaller or weirder architectures. For example, LLVM has this annoying tendency to really aggressively promote the size of everything--if you have a 32-bit core with 64-bit memory indexing, LLVM tends to make anything that eventually becomes a memory index a 64-bit computation, even if it would be more efficient to keep everything as 32-bit.

Re: Usability Improvements in GCC 15

#73
post #21

Earlier quoted context omitted.

I believe clang has worked for years now.

Why would anyone bother with GCC then? :P

GCC still for Linux distributions using glibc or any other library with many "GCCisms". Also, I'm not sure whether or not Clang is ABI compatible enough for enterprise customers with some rather extreme backwards compatibility requirements. Still, I can imagine a future where glibc can be built with Clang, possibly even one where llvm-libc is "good enough" for many users.

Re: Usability Improvements in GCC 15

#74
post #24

Earlier quoted context omitted.

It's in the spirit of adding emojis to compiler output...

I actually quite like the emojis they put in the output, it helps alleviate the balance of providing enough context while also giving a clear visual indicator for the actual error message. They aren't going overboard on it, they just put a warning emoji in front of the error message.

How do you grep for it without taking your hands off the keyboard?

Re: Usability Improvements in GCC 15

#75
post #47

Earlier quoted context omitted.

I believe GCC still wins by far on support for weird CPUs and embedded systems.

With LLVM I doubt this will remain true. LLVM makes custom code generation far too easy for GCC to remain viable imo.

Hm, is it so much easier to write an LLVM back-end than a GCC back-end? I haven't looked into GCC's code gen infrastructure that much, but I looked into making a new back-end to LLVM some time ago and it seemed extremely complex and entirely undocumented. All guidance I found on it basically amounted to, "copy an existing back-end and bang it against a rock until you've made it generate the machine code you need". And it certainly wasn't a case of having clean and simple enough code to make documentation unnecessary. It would honestly surprise me if GCC is more difficult to add a back-end to.

Re: Usability Improvements in GCC 15

#76

Big fan of all of this except for the emojis in my console

On the one hand I feel like the #WARNING_SIGN is a welcome addition. On the other, I'm sensitive to the idea that it will be totally obnoxious if you need to grep/search for it in whatever tool you're using. Was a little surprised to learn that the warning sign is generally considered an Emoji; I guess I don't think of it that way. Was even more surprised to learn that there is no great definition for what constitute…

> Was even more surprised to learn that there is no great definition for what constitutes an Emoji. The term doesn't seem to have much meaning in Unicode

The definition is messy, but the list of Unicode emojis is defined. Starting points: https://www.unicode.org/reports/tr51/, https://unicode.org/emoji/charts/full-emoji-list.html

Re: Usability Improvements in GCC 15

#77

Earlier quoted context omitted.

You can already put multi-column-wide non-ASCII characters in your source code, so the horse has left the barn already.

Of course you can . I'd argue you shouldn't, but that's beside the point. There is clearly a difference between people being able to do something, and the compiler forcing it on them.

But the compiler isn't forcing it on anyone?

Re: Usability Improvements in GCC 15

#78
post #7

Usability improvement request for this article: don't hijack the browser back button :P

Browser makers should straight up remove the JS API for interacting with history. There are legitimate uses for it, but the malicious actors far outweigh the good ones at this point. Just remove it.

Ditto for unprompted redirects.

Re: Usability Improvements in GCC 15

#80
post #47

Earlier quoted context omitted.

I believe GCC still wins by far on support for weird CPUs and embedded systems.

With LLVM I doubt this will remain true. LLVM makes custom code generation far too easy for GCC to remain viable imo.

The problem is that "weird CPUs and embedded systems" are not mainstream platforms, nor do they have a lot of money behind them (particularly for open source development). Hence, there is little motivation and/or resources for anyone to develop a new backend for LLVM when a mature GCC backend already exists. Moreover, the LLVM developers are weary to accept new backends for niche platforms when there is no guarantee that they will be maintained in the future.
Post reply on HN