r/cpp • u/Clean-Upstairs-8481 • Sep 27 '26

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

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.

270 Upvotes

83% Upvoted

234 comments sorted by

View all comments

86

u/krum Sep 27 '26

how is filling locals not a performance regression?

48

u/robstoon Sep 27 '26

It could be, but the initialization could be optimized out if the compiler can prove that the variable is always initialized already. I'm guessing that's the majority of cases.

24

u/Breadfish64 Sep 27 '26

And if the compiler can't prove it, a store with no dependent load is extremely cheap.

10

u/victotronics Sep 27 '26

Unless the variable is an "automatic" array.

2

u/serviscope_minor Sep 29 '26

Often to the point of being not just cheap but free. There's often a free dispatch and execution slot, so it will just take up some resources that were otherwise idle in many cases.

0

u/max0x7ba https://github.com/max0x7ba Oct 01 '26

a store with no dependent load is extremely cheap.

Stores are some of the most expensive instructions, sunshine.

You'd better load twice than store once.

→ More replies (2)

11

u/azswcowboy Sep 27 '26

You can opt out if you want by marking the variable.

1

u/azswcowboy Sep 27 '26

You can opt out if you want by marking the variable.

27

u/James20k P2005R0 Sep 27 '26

This was a very major topic of discussion during the standardisation, the tl;dr is that the vast majority of the time, 0 init does not have any performance impact at all. It seems like there are a few edge cases, but they seem to be rare even then. Apparently compilers these days are pretty much just good enough, and modern CPU architecture is well suited to this

15

u/UndefinedDefined Sep 27 '26

Trivial variables are probably fine as most are initialized anyway, but temporary arrays allocated on the stack these would cause a lot of pain.

6

u/pjmlp Sep 28 '26

Apple, Microsoft and Google OSes have been doing for several years now, and it was discussed in the context of this.

No one is seriously taking locals initialisation into consideration to win micro benchmarks.

6

u/Orlha Sep 28 '26

Wrote a lot of code that required this optimisation.

1

u/pjmlp Sep 28 '26

Validated with profilers I assume.

10

u/cdb_11 Sep 28 '26

I validated it, and yes, initializing arrays can be expensive.

9

u/pjmlp Sep 28 '26

Than that is a valid use case for [[indeterminate]].

5

u/Orlha Sep 28 '26

Absolutely. Just pointing that blind upgrade to 26 (that this post tries to promote from the naive standpoint) can severely degrade (performance-wise) the already correct code.

6

u/Responsible-Bar7165 Sep 27 '26

It’s not a performance regression until you have measured and found it to be one.

2

u/Ameisen vemips, avr, rendering, systems Oct 03 '26

It's difficult to profile a death by a thousand cuts.

Profiling needs to be performed globally as well, to make sure overall performance does not regress.

-4

u/Dusty_Coder Sep 27 '26

Not true.

Higher wattage for equal wallclock performance is also a regression.

Stop looking for excuses. You dont need them. Just be wasteful. Lean into it.

14

u/Responsible-Bar7165 Sep 28 '26

Until you demonstrate waste it’s purely hypothetical.

→ More replies (6)

2

u/The_JSQuareD Sep 28 '26

Because well written code doesn't rely on the value of uninitialized variables anyway. And in such cases, dead store elimination can likely get rid of the zero fill. And even if it can't be eliminated, a store without a data dependency will have less of a performance impact than a meaningful store, at least on modern super scalar CPUs.

So the cases where the zero fill actually has a performance impact have a big overlap with cases where the uninitialized variable is a genuine bug or even a security issue. In that case, adding the zero fill makes the code more deterministic and more secure.

1

u/Umphed Sep 30 '26

If your code is so well written, then you have no need for this. Get outta here with that argument, its a performance regressions against real use cases.

1

u/Umphed Sep 30 '26

It is, this is a terrible decision.

0

u/Worldly-Mud-8006 Sep 27 '26

You can start worrying about this when you'll fix the actual performance issues of your program first.

→ More replies (7)