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

GCC 14.1

gcc.gnu.org

Post reply on HN
Print view View original

11–20 of 55 posts

Re: GCC 14.1

#11

Post by rwmj »

mid-kid wrote: post #8

It's worth noting that this release breaks a lot of older code, see: https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3... It enables a few -Werror flags by default, refusing to compile code with probable undefined behavior. Unfortunately, a lot of older code subtly raises these warnings (now hard errors), even in cases where it's "fine" (due to valid platform assumptions).

This is true but by now distros have fixed most of the breakage and sent the changes back upstream (certainly this is true for Fedora).

Re: GCC 14.1

#12

Post by mid-kid »

rwmj wrote: post #11
mid-kid wrote: post #8

It's worth noting that this release breaks a lot of older code, see: https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3... It enables a few -Werror flags by default, refusing to compile code with probable undefined behavior. Unfortunately, a lot of older code subtly raises these warnings (now hard errors), even in cases where it's "fine" (due to valid platform assumptions).

This is true but by now distros have fixed most of the breakage and sent the changes back upstream (certainly this is true for Fedora).

Well, yeah, for maintained upstreams. I sometimes need to build older versions of software and simply use unmaintained software, for which these changes are a bit of a pain, along with -fno-common before it.

Re: GCC 14.1

#13

Post by dkjaudyeqooe »

ropejumper wrote: post #10
mirekrusin wrote: post #7

Is Ada being used in the industry? Looks actually quite fun to play with from changelog additions. I didn’t realise it’s still under active development.

It's pretty famously used by the US government for safety-critical software.

Also avionics and air traffic control

Re: GCC 14.1

#15

Post by dkjaudyeqooe »

dailykoder wrote: post #6
rwmj wrote: post #5

Earlier quoted context omitted.

With hopefully more to come! There's a RISE project proposal being kicked around to improve vectorization support.

I didn't realize RISC-V already has so many extensions. I just briefly looked over them and apparently they are often just small parts which get grouped up into larger extensions, but I hope the extension "mess" won't kill risc-v in the end. Still very excited about RISC-V progress

For RISC-V, it's extensions all the way down. The mandatory core is tiny and all the value (outside of minuscule microcontrollers) is in the extensions.

It makes more sense if you think about it like programming libraries. That's the same 'mess', but it's not a problem.

There is often fear of 'fragmentation', but vendors tend to be highly responsive to their target market and competitors for each application and will coalesce around a set of extensions that make sense.

The other thing I'd add is that the one thing worse than having 'yet another extension' is not having the extension you need. Extensions are a response to market demand.

Re: GCC 14.1

#16

Post by softgrow »

Probably should have made this comment 20-25 years ago but anyway. Always was impressed that with each new release that my application ran that bit faster on the same code, so thank you backend people (SPARC). Lots of fun to bootstrap too and compile the compiler and check it stays the same. Although to be fair bootstrapping Kermit from nothing was a more impressive process.

Re: GCC 14.1

#17

Post by dooglius »

mid-kid wrote: post #8

It's worth noting that this release breaks a lot of older code, see: https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3... It enables a few -Werror flags by default, refusing to compile code with probable undefined behavior. Unfortunately, a lot of older code subtly raises these warnings (now hard errors), even in cases where it's "fine" (due to valid platform assumptions).

Very easily worked around with -Wno

Re: GCC 14.1

#18

Post by mikepurvis »

mid-kid wrote: post #12
rwmj wrote: post #11

Earlier quoted context omitted.

This is true but by now distros have fixed most of the breakage and sent the changes back upstream (certainly this is true for Fedora).

Well, yeah, for maintained upstreams. I sometimes need to build older versions of software and simply use unmaintained software, for which these changes are a bit of a pain, along with -fno-common before it.

At a certain point, it's probably easier to build and run the unmaintained software in a container running an OS of corresponding vintage. Obviously that has security ramifications, but hopefully this software isn't facing the internet and being in a container at least means you're on a modern kernel and can isolate things at a port and filesystem level.

Re: GCC 14.1

#19

Post by emidln »

mid-kid wrote: post #8

It's worth noting that this release breaks a lot of older code, see: https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3... It enables a few -Werror flags by default, refusing to compile code with probable undefined behavior. Unfortunately, a lot of older code subtly raises these warnings (now hard errors), even in cases where it's "fine" (due to valid platform assumptions).

It's great seeing progress made here. C/C++ will never be truly safe languages, but every little bit the compiler can help with is appreciated, esp by those maintaining established codebases.

Re: GCC 14.1

#20

Post by mikepurvis »

dkjaudyeqooe wrote: post #15
dailykoder wrote: post #6

Earlier quoted context omitted.

I didn't realize RISC-V already has so many extensions. I just briefly looked over them and apparently they are often just small parts which get grouped up into larger extensions, but I hope the extension "mess" won't kill risc-v in the end. Still very excited about RISC-V progress

For RISC-V, it's extensions all the way down. The mandatory core is tiny and all the value (outside of minuscule microcontrollers) is in the extensions. It makes more sense if you think about it like programming libraries. That's the same 'mess', but it's not a problem. There is often fear of 'fragmentation', but vendors tend to be highly responsive to their target market and competitors for each application and will…

Speaking as someone with zero actual domain knowledge, my concern would be about ensuring that disparate extensions have consistent interfaces and can cooperate with each other. I don't know how that would work at a hardware design level, but the thing to avoid would be whatever is the analogue of the rust/async fiasco, where certain components only really work properly with others within their own "sub" ecosystem.
Post reply on HN