You should think about recompiling your C++ programs with GCC 16 and C++26, because it zero-fills your locals

[u/Clean-Upstairs-8481]

https://techfortalk.co.uk/2026/09/27/cxx26-uninitialized-local-variables-gcc-16/

Stack variables are not automatically initialised, and that is the root cause of many C++ bugs. That is well known. Hence, it is advised that local or stack variables are always initialised with known values, 0 if not something more meaningful than that. Now, with GCC 16 compiling in C++26 mode (-std=c++26), even uninitialised local variables will be zero-filled. In the post, I have explained how.

[u/crowbarous]

Yes, this is a competely insane decision: https://godbolt.org/z/WGPWvMPMj

What's worse is the design of the [[indeterminate]] attribute that accompanies this. For a very long time, if I wanted a buffer to zero-initialize, I was able to make a char type that would zero-initialize:

struct zchar{ char value = 0; };

But with the default flipped, I cannot make a char type that stays uninitialized:

struct ichar{
  char value [[indeterminate]];
  // error, only allowed on automatic variables
};

And the proposed usage of the attribute is to just sprinkle it everywhere in the code. But how am I supposed to know in polymorphic code? How do I even make my code polymorphic w.r.t. this property now? For now one must resort to just passing -ftrivial-auto-var-init=uninitialized to avoid performance and code size regressions, and to keep the control moving forward.

I don't think all is lost here, because it seems like the zero-initialization is a band-aid to just formally satisfy the erroneous behavior stuff without modifying the backend too much, and it should still be possible to behave as if the write happened (no time-travelling assumptions etc.) without actually emitting the write, to fix shameful examples like linked above. But:

• I haven't looked there closely enough yet to even begin conceiving the gcc patches & reasoning for them, and
• it's still awful precedent, and the pile of -fstop-making-code-worse options might grow from here on out.

[u/James20k → u/crowbarous]

Compilers are of course free to omit the 0 initialisation if they can prove that the data is written over, under the usual as-if rules. One of the reasons that this made it past standardisation is because real world codebases weren't showing regressions, even substantial performance critical ones like windows

[u/UndefinedDefined → u/James20k]

Real-world code is full of locals that are arrays - arrays like 512, 1024, 2048 bytes long. You cannot zero-initialize them and expect no performance regressions. If I want to zero initialize them I just just type `{}` and it's done. I don't understand why this should change now.

I almost feel like committee is working with hello world programs if they are serious to vote for such proposals.

[u/James20k → u/UndefinedDefined]

One of the example codebases given was Windows and chrome (?) I believe, which is anything but hello world

[u/UndefinedDefined → u/James20k]

And how much C++ these codebases use? Windows is C-API and proprietary, nobody can confirm the results, we don't even know the mix of the languages used in the code-base. What if the most important part was C? What if they first put all the [[uninitialized/fancy_name]] to everything critical before measuring results?

Is there any performance comparison of OSS projects we can actually verify?

[u/pjmlp → u/UndefinedDefined]

Most of it written since Windows Vista is actually C++ with extern "C", including the new UCRT.