gh-142168: explicitly initialize stack_array in _PyEval_Vector and _PyEvalFramePushAndInit_Ex

[gkirchou]

To stop the warning.

Reproduce steps:

./configure --enable-optimizations --with-lto
make -s -j $(nproc);

• Issue: _PyEvalFramePushAndInit_Ex warning: 'stack_array' may be used uninitialized #142168

[StanFromIreland]

We already have #132376 open for this (we also had #134207, but that's closed now).

[chris-eibl]

See my comment on the issue. There is prior art and initializing in this hot path to silence a false positive warning is not (my) preferred solution.

[picnixz]

Initialization in a hot path is not desired and it's also a false positive. I'm going to close this PR, sorry.

[vstinner]

IMO this change is a reasonable fix for the warnings.

[picnixz]

I think we should have checked the produced assembly to see whether this introduces a true overhead in an optimized build. Personally, I think the pragmas are fine (we do this elsewhere) but we could disable them in DEBUG mode so that we correctly catch a possible issue when it's not optimized.

[chris-eibl]

Well, we can check and then we know for this compiler and version we've checked. And are at the mercy of all compilers and versions that they hopefully behave the same - i.e. do not produce needless initialization code we've put in to silence a false positive warning.

[chris-eibl]

I think the pragmas are fine

I think so, too. It is good to have less warnings. It is even better to have less false positive warnings :)

[chris-eibl]

OTOH, _PyEvalFramePushAndInit_Ex is not very hot and compared to what the function is doing, the initialization most probably will be lost in noise.
It just bugs me to let the compiler emit unneeded code ¹ and to have to think about whether it is impactful or not when I know it definitely isn't needed ...
So I'll leave it up to others to decide how to get rid of the warning and am just happy when the warning is gone :)

Footnotes

1. maybe I should use "potentially unneeded code": some compilers might be smart enough to omit it, most probably those that don't emit the warning :) ↩

[chris-eibl]

Reopening per my comment above ...

[picnixz]

If we want pragmas we have the other PR which should be preferred over this one.

It we want an explicit initialization we can use this one. OTOH while it is a false positive it may become a non-false positive if we were to change the code a bit so it may be worth doing the explicit initialiaztion.

[vstinner]

LGTM. IMO it's a reasonable fix to avoid warnings about uninitialized variables.

[chris-eibl]

As said I am fine either way and happy when the warning is gone.

Leaving up to @markshannon or @Fidget-Spinner.

[Fidget-Spinner]

_PyEvalFramePushAndInit_Ex is only used by _DO_CALL_FUNCTION_EX. That uop already constructs a tuple args and ocassionally dict kwargs. This is thus nothing in comparison to those. We should just merge it. Any effect on performance is likely not even measurable.

[picnixz]

Actually, the commit is not by this author?

EDIT: oh this is just an alt account, looks like the same person.

[picnixz]

@Fidget-Spinner What about _PyEval_Vector?

[Fidget-Spinner]

_PyEval_Vector is a little trickier. It's actually in the hot path of vectorcalls to Python functions in C-to-Python calls. However, again I suspect the cost of this is so low with respect to everything else (frame creation and all that) it doesnt matter.

[picnixz]

Let's merge this and if there is a noticeable performance loss, then people will complain :')