gh-132314: fix stack array init warning

[dura0ok]

Dummy warning fix

• Issue: The small_stack variable is (incorrectly) flagged as used uninitialized #132314

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[dura0ok]

There was no warning with the configuration without options, but I reproduced it with the --enable-optimization --with-lto options. The mistake is very simple.

[chris-eibl]

IMHO, the compiler warning is a false-positive.

If the stack_array is used

cpython/Python/ceval.c

Lines 1832 to 1834 in ad3bbe8

	if (nargs <= 8) {
	newargs = stack_array;
	}

it is initialized

cpython/Python/ceval.c

Lines 1844 to 1846 in ad3bbe8

	for (Py_ssize_t i = 0; i < nargs; i++) {
	newargs[i] = PyStackRef_FromPyObjectNew(PyTuple_GET_ITEM(callargs, i));
	}

Having a small array on the stack to avoid the PyMem_Malloc is a common pattern, e.g. further down

cpython/Python/ceval.c

Line 1880 in ad3bbe8

_PyStackRef stack_array[8];

or like mentioned in the issue #132314

cpython/Python/bltinmodule.c

Line 1450 in ad3bbe8

PyObject *small_stack[_PY_FASTCALL_SMALL_STACK];

They all follow the same pattern, and if the compiler is not smart enough to detect it, it will issue a warning.

IMHO, initializing those stack variables using = {} is a waste of CPU cycles, and we should silence the warning using a diagnostic pragma.

[dura0ok]

I think hiding warnings using pragma it is not good idea, because we have other compilers.

[chris-eibl]

Yeah, but not all of them emit the warning, so we only have to silence those that do?

[picnixz]

Yes and we can selectively decide which compilers need to be silenced as well so I think for a falsey positive like that it's better to silence the warning.

[dura0ok]

Fixed. Check please new version. @chris-eibl @picnixz

[chris-eibl]

Sorry @dura0ok, I totally missed this one - but #134207 rang a bell and so I am here again.

I had a simpler approach in mind just using a pragma for GCC directly in the affected places but I like your approach, too, since it is re-usable.

There is already infrastructure and I'd place the macro next to

cpython/Include/pyport.h

Lines 297 to 302 in c740fe3

	#if defined(__clang__)
	#define _Py_COMP_DIAG_PUSH _Pragma("clang diagnostic push")
	#define _Py_COMP_DIAG_IGNORE_DEPR_DECLS \
	_Pragma("clang diagnostic ignored \"-Wdeprecated-declarations\"")
	#define _Py_COMP_DIAG_POP _Pragma("clang diagnostic pop")
	#elif defined(__GNUC__) \

I'd also go with the naming scheme used there, e.g. _Py_COMP_DIAG_IGNORE_MAYBE_UNINITIALIZED, and use it like

cpython/Modules/main.c

Lines 522 to 530 in c740fe3

	static void
	pymain_set_inspect(PyConfig *config, int inspect)
	{
	config->inspect = inspect;
	_Py_COMP_DIAG_PUSH
	_Py_COMP_DIAG_IGNORE_DEPR_DECLS
	Py_InspectFlag = inspect;
	_Py_COMP_DIAG_POP
	}

[picnixz]

We eventually decided to have an explicit initialization so we won'tuse pragmas but this can be useful in the future for fixing expensive false positive, so thank you!