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

41–50 of 55 posts

Re: GCC 14.1

#41

Post by pjmlp »

ho_schi wrote: post #40
pjmlp wrote: post #34

Earlier quoted context omitted.

It is only yet another wannabe C++ replacement, regardless how it is sold as not being one.

A wannabe replacement by…Herb Sutter. I dare to differ.

Which is exactly why he pretends to not be a wannabe replacement, as it is politically incorrect to have the chair of ISO C++ to also propose a C++ replacement.

CFront wasn't C, nor Objective-C was C, even though both originally started as macro preprocessors targeting C code generation, and were like Typescript for C.

They became their own thing, after enough user based was won, and nowadays all major C compilers and standard libraries are written in C++, not C.

Re: GCC 14.1

#42

Post by hulitu »

jcranmer wrote: post #25
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).

Looking at those flags, several of them are erroring about things that have been deprecated since before I was born. If you're going to complain that it's breaking old code, I have to ask why this code is simultaneously important enough to you to use a modern compiler with modern flags to build it and not important enough to bother changing for 30 years.

> things that have been deprecated since before I was born.

You must be very young.

Breaking compilation is not a sign of maturity. See Rust for details.

Re: GCC 14.1

#43

Post by gizmo686 »

hulitu wrote: post #42
jcranmer wrote: post #25

Earlier quoted context omitted.

Looking at those flags, several of them are erroring about things that have been deprecated since before I was born. If you're going to complain that it's breaking old code, I have to ask why this code is simultaneously important enough to you to use a modern compiler with modern flags to build it and not important enough to bother changing for 30 years.

> things that have been deprecated since before I was born. You must be very young. Breaking compilation is not a sign of maturity. See Rust for details.

Rust is 9 years old. By programming language standards, it is the new kid around the block.

C is over 50 years old.

Python is 30.

Haskell 35

Java 30

Re: GCC 14.1

#44

Post by crabique »

crabique wrote: post #14

Has the LTO bug affecting Ceph client been fixed in this? I don't see a mention of this ticket in the changelog, but in the issue itself it sounds like they managed to resolve it: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359

Upd: searching in the github mirror by the commit hash from the issue, found that https://github.com/gcc-mirror/gcc/commit/1e3312a25a7b34d6e3f... is in fact in the 'releases/gcc-14.1.0' tag.

Even weirder that this one got swept under the changelog rug, it's a pretty major issue.

Re: GCC 14.1

#45

Post by sqeaky »

dooglius wrote: post #17
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

I might be wrong, but it is my understanding that a lot of these warnings deal with undefined or implementation defined behavior and that behavior is changing this release. If that understanding is close, for even some of these, then just suppressing the warnings means the software will behave differently.

Re: GCC 14.1

#46

Post by mid-kid »

jcranmer wrote: post #25
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).

Looking at those flags, several of them are erroring about things that have been deprecated since before I was born. If you're going to complain that it's breaking old code, I have to ask why this code is simultaneously important enough to you to use a modern compiler with modern flags to build it and not important enough to bother changing for 30 years.

Plenty of software broke as a result of these flags, gentoo has a tracker here: https://bugs.gentoo.org/showdependencytree.cgi?id=870412&hid...

As per my own experiences so far, we maintain an older version of GCC for matching GBA decompilation projects, which exhibits compilation errors now.

Re: GCC 14.1

#47

Post by mid-kid »

Phyx wrote: post #35
cozzyd wrote: post #30

Earlier quoted context omitted.

it would be nice if they provided a gcc-ancient-compat or something though it's easy enough to create an alias with the correct flags.

-std=gnu98 works. ie explicitly telling it your code is not modern C.

The new flags apply regardless of -std value, as does -fno-common

Re: GCC 14.1

#48

Post by mid-kid »

mikepurvis wrote: post #18
mid-kid wrote: post #12

Earlier quoted context omitted.

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.

You're right, but it's also significantly more inconvenient.

Re: GCC 14.1

#49

Post by mid-kid »

sqeaky wrote: post #45
dooglius wrote: post #17

Earlier quoted context omitted.

Very easily worked around with -Wno

I might be wrong, but it is my understanding that a lot of these warnings deal with undefined or implementation defined behavior and that behavior is changing this release. If that understanding is close, for even some of these, then just suppressing the warnings means the software will behave differently.

Nah, you can override the flags and still will remain working, but you have to be aware of it and figure out how to change the flags of a project properly.

Re: GCC 14.1

#50

Post by dooglius »

sqeaky wrote: post #45
dooglius wrote: post #17

Earlier quoted context omitted.

Very easily worked around with -Wno

I might be wrong, but it is my understanding that a lot of these warnings deal with undefined or implementation defined behavior and that behavior is changing this release. If that understanding is close, for even some of these, then just suppressing the warnings means the software will behave differently.

My understanding is that these were all existing warnings that were off by default (you needed to pass -Wall to see) that are now displayed by default; I don't see any indication in the patch thread that there were corresponding behavior changes.
Post reply on HN