Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Usability Improvements in GCC 15

developers.redhat.com

Post reply on HN
Print view View original

151–160 of 231 posts

Re: Usability Improvements in GCC 15

#151

Post by kstrauser »

Keyframe wrote: post #145
School-Cotton wrote: post #53

Earlier quoted context omitted.

But the person you're responding to never said he was shocked or disappointed by the views; he just said the views are bad/counterproductive.

I found out the older I get the more sense rms makes.

On the subject of software freedom, I hate how accurately prophetic he is.

RMS: Here’s how they'll get ya!

Me: Nice, but that'd never happen.

Vendor: Here’s how we got ya!

Me: Dammit.

Seriously, he must have a working crystal ball.

Now, my agreement with him starts and ends on that subject. He says plenty of other things I wholly disagree with. But his warnings about proprietary software lock-in? Every. Single. Time.

Re: Usability Improvements in GCC 15

#152

Post by jart »

Here's the pending GCC 15 release notes: https://gcc.gnu.org/gcc-15/changes.html (since the link in the article points to GCC 14)

- I'd love to see godbolt examples of the sort of optimizations [[unsequenced]] and [[reproducible]] can do.

- GCC has always been in my experience smart enough to know how to optimize normal C code into ROL and ROR instructions. I've never had any issues with it. So what's the point of __builtin_stdc_rotate_left()? Why create a builtin when it is not needed? What I wish GCC and Clang would do instead, is formally document the magic ANSI C89 incantations that trigger the optimization, e.g. `#define ROL(x, n) (((x) > (64 - (n))))`. That way we can have clean portable code with less #ifdef hell along with assurances it'll go fast when -O is passed.

- What is "Abs Without Undefined Behavior (addition of builtins for use in future C library headers)."?

- What is "Allow zero length operations on null pointers"?

- Re: "Introduce complex literals." How about some __int128 literals?

- "The "redzone" clobber is now allowed in inline assembler statements" wooo I've wanted something like this for a while.

Great work from the greatest compiler team!

Re: Usability Improvements in GCC 15

#154

Post by jart »

bigstrat2003 wrote: post #68
mwkaufma wrote: 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.

That's a biased thing to say, since you're never going to notice the times when the history api is being used appropriately. Just as often I find myself raging when a webpage doesn't rewrite history at times when it should. Good taste is hard to come by.

Re: Usability Improvements in GCC 15

#155

Post by trashburger »

eddd-ddde wrote: post #97
munificent wrote: post #36

Using a hierarchy to show template errors is brilliant and I'm sort of surprised compilers haven't always done that. I was investigating C++-style templates for a hobby language of mine and SFINAE is an important property to make them work in realistic codebases, but leads to exactly this problem. When a compile error occurs, there isn't a single cause, or even a linear chain of causes, but an potentially arbitrarily…

I really wish templates didn't work on a dumb "replace at call site until something compiles" manner. All template requirements should be verified at the function definition, not at every call site. There is concepts. But they are so unwieldy.

Please no. Templates being lazy is so much better than Rust's eager trait evaluation, the latter causing incredible amounts of pain beyond a certain complexity threshold.

Re: Usability Improvements in GCC 15

#156

Post by jart »

codeshaunted wrote: post #44
bombcar wrote: post #21

Earlier quoted context omitted.

I believe clang has worked for years now.

Why would anyone bother with GCC then? :P

GCC is still marginally superior at both code size and performance in my experience.

The main thing I like about clang is it compiles byzantine c++ code much faster.

Some projects like llama.cpp it's like eating nails if you're not using clang.

So with projects like llamafile I usually end up using both compilers.

That's why my cosmocc toolchain comes with -mgcc and -mclang.

Re: Usability Improvements in GCC 15

#157

Post by PaulDavisThe1st »

nightfly wrote: post #121
bigstrat2003 wrote: post #68

Earlier quoted context omitted.

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.

This type of thinking is what doomed uBlock Origin. I strongly disagree.

How is uBlock Origin "doomed" ?

Re: Usability Improvements in GCC 15

#158

Post by dzaima »

mort96 wrote: post #109
duped wrote: post #42

Earlier quoted context omitted.

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 tha…

Forcing vendors to contribute back upstream is an attempt at making vendor toolchains not exist. If a company makes a new MCU with some exciting new instruction set, they need to make a compiler available which supports that instruction set and make that compiler available to their customers. With LLVM as the base, the vendor could make their toolchain proprietary, making it impossible to integrate it back into LLVM,…

gcc requires that contributors assign copyright to FSF (or at least "certify the Developer Certificate of Origin")[0], so a fork isn't gonna get upstreamed without the approval of the fork's authors. So that limits the benefit from gcc-forks to individuals keeping the fork alive.

[0]: https://gcc.gnu.org/contribute.html#legal

Re: Usability Improvements in GCC 15

#159

Post by throwaway2037 »

uecker wrote: post #82
duped wrote: 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

GCC has very good ISO compliance and ISO C23 is better supported than in Clang (which I expect to catch up soon though)

Knowing the history of GCC (more focused on C) and Clang (more focused on C++), it makes sense to me that GCC has better ISO C compliance.

Clang has a very nice specific page for ISO C version compliance: https://clang.llvm.org/c_status.html#c2x

I could not find the same for GCC, but I found an old one for C99: https://gcc.gnu.org/c99status.html

CppRef has a joint page, but honestly, I am more likely to believe a page directly owned/controlled/authored by the project itself: https://en.cppreference.com/w/c/compiler_support/23

Finally, is there a specific feature of C23 that you need that Clang does not support?

Re: Usability Improvements in GCC 15

#160

Post by alisonatwork »

nottorp wrote: post #103
perching_aix wrote: post #86

Earlier quoted context omitted.

Windows key + dot, then type in warning / if it was among the last ones you used, use the arrow keys, and hit Enter to insert it. If you use whatever OS other than Windows, I'm sure there are similar flows available if you search for it. And since it's just Unicode, I'm sure there are numpad based keybinds available too.

why shouldn't i just type grep warning instead of bringing up some GUI that possibly takes forever to initialize? how does it work over ssh? :)

Emoji selector is fast and works perfectly fine over SSH, it's no different to any other input method that needs to use characters beyond 7-bit ASCII.

grep is a bit more iffy. UNIX command line tools seem to be a bit of a crapshoot in how or if they support Unicode, especially if you switch between different systems like Linux, BSD, Cygwin etc. You might need a bit of experimenting with the LANG variable to get it work (e.g. Git Bash on Windows needs LANG=C.UTF16 to match an emoji). I've also had cases where grep or sed works, but awk doesn't, or vice versa. On the whole it works a lot better nowadays than it used to, though, and that's a win for non-English users of the command line as well as emoji fans.

Post reply on HN