Live data from Hacker News

Usability Improvements in GCC 15

developers.redhat.com

41–50 of 231 posts

Re: Usability Improvements in GCC 15

#41
post #5

Earlier quoted context omitted.

GCC can honestly only blame itself for its inevitable increasing obsolescence. LLVM only has the attention it has because it can be used as a building block in other compilers. GCC could've made a tool and library which accepts IR, performs optimizations and emits machine code, but the project avoided that for ideological reasons, and as a result created a void in the ecosystem for a project like LLVM.

Is it still the case that the Linux kernel cannot be compiled using clang, or can you do that now?

https://static.lwn.net/kerneldoc/kbuild/llvm.html

I do remember reading about LTO not working properly, you're either unable to link the kernel with LTO, or get a buggy binary which crashes at runtime. Doesn't look like much effort has been put into solving it, maybe it's just too large a task.

Re: Usability Improvements in GCC 15

#42
post #17
post #15

Earlier quoted context omitted.

It's not like GCC or the embedded toolchains are a shining beacon of ISO compliance... and if you mean video game consoles, are any of them using GCC today? Sony and Nintendo are both LLVM and Microsoft is Microsoft

The difference being that vendors forks not compliant with GPL can be legally asked for the changes they haven't sent upstream.

With LLVM they don't need to fork it in the first place. But still, it doesn't matter because ISO compliance is a frontend problem.

The one vendor who forks LLVM and doesn't contribute their biggest patches back is Apple, and if you want bleeding edge or compliance you're not using Apple Clang at all.

If you say "isn't it great vendor toolchains have to contribute back to upstream?" I'm going to say "no, it sucks that vendor toolchains have to exist"

Re: Usability Improvements in GCC 15

#45
post #8
post #5

Earlier quoted context omitted.

GCC can honestly only blame itself for its inevitable increasing obsolescence. LLVM only has the attention it has because it can be used as a building block in other compilers. GCC could've made a tool and library which accepts IR, performs optimizations and emits machine code, but the project avoided that for ideological reasons, and as a result created a void in the ecosystem for a project like LLVM.

The embedded compiler vendors, UNIX and consoles are quite happy with it. How much do you think they contribute back upstream regarding ISO compliance outside LLVM backend for their hardware and OS?

Apple, Arm, OpenBSD, FreeBSD have all switched to Clang.

Re: Usability Improvements in GCC 15

#46

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

Why?

Well, other than the fact that it's hard to search for, things should be kept as simple as possible to improve reliability/interoperability. Are you confident that multi-column-wide non-ASCII characters work reliably without causing rendering issues on every possible combination of terminal/shell/OS, including over SSH? I'm certainly not.

Re: Usability Improvements in GCC 15

#48

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…

How will it output on my VT100 serial terminal? :P

Somewhat related fun fact, anyone can submit an emoji to the Unicode Consortium annually, submissions are actually open right now: https://unicode.org/emoji/proposals.html.

Re: Usability Improvements in GCC 15

#49
post #8
post #5

Earlier quoted context omitted.

GCC can honestly only blame itself for its inevitable increasing obsolescence. LLVM only has the attention it has because it can be used as a building block in other compilers. GCC could've made a tool and library which accepts IR, performs optimizations and emits machine code, but the project avoided that for ideological reasons, and as a result created a void in the ecosystem for a project like LLVM.

The embedded compiler vendors, UNIX and consoles are quite happy with it. How much do you think they contribute back upstream regarding ISO compliance outside LLVM backend for their hardware and OS?

What exactly do you mean by "UNIX"? Commercial UNIX vendors other than Apple have basically a rounding error from 0% of market share.
Post reply on HN