GCC 16 has been released • Hacker News Board

Re: GCC 16 has been released

#31

Post by jandrewrogers » Thu, Apr 30, 2026, 3:42 PM UTC

kevin_thibedeau wrote: post #29

jandrewrogers wrote: post #25

Earlier quoted context omitted.

There was already a legal way to achieve this that everyone should already have been using (laundering a pointer through a no-op memmove). Using reinterpret_cast here is a bug. The "start_lifetime_as" facility does one additional thing beyond providing a tidy standard name for the memory laundering incantation. Semantically it doesn't touch the memory whereas the no-op memmove intrinsically does. In practice, this ma…

This still has unresolved alignment issues that blow up outside the amd64 ecosystem.

Is this just a basic lack of alignment enforcement or is there a bigger issue?

Re: GCC 16 has been released

#32

Post by amluto » Thu, Apr 30, 2026, 3:45 PM UTC

gavinray wrote: post #11

I want to point out an implemented feature that people SHOULD be adopting but that I doubt will be picked up: P2590R2, Explicit lifetime management (PR106658) This is for "std::start_lifetime_as ". If you have not heard of this before, it's the non-UB way to type-pun a pointer into a structured type. Nearly all zero-copy code that deals with external I/O buffers looks something like: std::unique_ptr buffer = stream->…

The cppreference description seems questionable to me:

> Implicitly creates a complete object of type T (whose address is p) and objects nested within it. The value of each created object obj of TriviallyCopyable type U is determined in the same manner as for a call to std::bit_cast(E) except that the storage is not actually accessed, where E is the lvalue of type U denoting obj. Otherwise, the values of such created objects are unspecified.

So T is the complete new object. It contains subobjects, and one of those subobjects has type U. U is initialized as if by bit_cast, and I presume they meant to say that bit_cast casted from the bits already present at the address in question. Since “obj” is mentioned without any definition of any sort, I’ll assume it means something at the correct address.

But what’s E? The page says “E is the lvalue of type U denoting obj,” but obj probably has type char or a similar type, and if it already had type U, there would be no need for bit_cast.

Re: GCC 16 has been released

#33

Post by pjmlp » Thu, Apr 30, 2026, 3:46 PM UTC

gpderetta wrote: post #4

tosti wrote: post #3

Earlier quoted context omitted.

IIRC, since GCC got covered by GPL3. It used to be slower and I've spent way too much time working around C++ bugs in GCC 2.95 (The fact that I remember the problematic version is telling :)

Everybody remembers that specific version :). And I wasn't even programming professionally at that time!

Ah the egcs drama.

Re: GCC 16 has been released

#34

Post by wg0 » Thu, Apr 30, 2026, 3:57 PM UTC

Noob question - Does gcc use LLVM anywhere under the hood or it has its own code generation and optimization pipeline? How does it stack in comparison to LLVM?

Re: GCC 16 has been released

#35

Post by mshockwave » Thu, Apr 30, 2026, 4:03 PM UTC

wg0 wrote: post #34

Noob question - Does gcc use LLVM anywhere under the hood or it has its own code generation and optimization pipeline? How does it stack in comparison to LLVM?

> Does gcc use LLVM anywhere under the hood

No

Re: GCC 16 has been released

#36

Post by jandrewrogers » Thu, Apr 30, 2026, 4:06 PM UTC

szmarczak wrote: post #30

jandrewrogers wrote: post #25

Earlier quoted context omitted.

There was already a legal way to achieve this that everyone should already have been using (laundering a pointer through a no-op memmove). Using reinterpret_cast here is a bug. The "start_lifetime_as" facility does one additional thing beyond providing a tidy standard name for the memory laundering incantation. Semantically it doesn't touch the memory whereas the no-op memmove intrinsically does. In practice, this ma…

No because the object does not exist after std::launder. It only exists after std::start_lifetime_as. The bytes being there says nothing about the object, per the C++ standard.

The compiler will create an implicit lifetime type at the memmove destination as required to give it defined behavior. Technically you don't even need std::launder, it is just far more convenient than the alternative.

Re: GCC 16 has been released

#37

Post by kouosi » Thu, Apr 30, 2026, 4:16 PM UTC

wg0 wrote: post #34

Noob question - Does gcc use LLVM anywhere under the hood or it has its own code generation and optimization pipeline? How does it stack in comparison to LLVM?

> Does gcc use LLVM anywhere under the hood or it has its own code generation and optimization pipeline? No it doesn't use LLVM > How does it stack in comparison to LLVM? Well it support more targets then LLVM and in most cases it generates similar if not better executable.

Re: GCC 16 has been released

#38

Post by denotational » Thu, Apr 30, 2026, 5:01 PM UTC

jcranmer wrote: post #17

groundzeros2015 wrote: post #13

Earlier quoted context omitted.

You’re allowed to type pun char buffers.

No, you're not. You're allowed to access any type via a char buffer. But the converse is not true (quoting https://eel.is/c++draft/expr#basic.lval-11 ): > An object of dynamic type Tobj is type-accessible through a glvalue of type Tref if Tref is similar ([conv.qual]) to: Tobj, a type that is the signed or unsigned type corresponding to Tobj, or a char, unsigned char, or std :: byte type. If a program attempts to acc…

If the type is an implicit-lifetime type, then you can legally create an unsigned char array, and then reinterpret_cast a pointer to that to a pointer to the type.

See https://eel.is/c++draft/intro.object#def:object,implicit_cre....

https://eel.is/c++draft/intro.object#15 is an example showing this with malloc; the subsequent paragraph further permits it to work with an unsigned char array.

Re: GCC 16 has been released

#39

Post by not2b » Thu, Apr 30, 2026, 5:13 PM UTC

uyjulian wrote: post #6

t-3 wrote: post #2

Somehow I never realized that GCC has a very regular release schedule until looking it up just now: https://gcc.gnu.org/develop.html

It has been that way since people from Cygnus (now RedHat->IBM) reorganized the project

That is why egcs was launched, to get around the inability of the old team to do gcc releases. The issues had little to do with ideology and were about fixing a broken process and replacing it with something that had a hope of working.

Re: GCC 16 has been released

#40

Post by kelnos » Thu, Apr 30, 2026, 5:16 PM UTC

wg0 wrote: post #34

Noob question - Does gcc use LLVM anywhere under the hood or it has its own code generation and optimization pipeline? How does it stack in comparison to LLVM?

GCC far far far predates LLVM. They do not share code.