New warning in the main (-Warray-bounds)

[skirpichev]

Bug report

Bug description:

$ cc --version
cc (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./configure -q && make -s
In file included from ./Include/internal/pycore_dict.h:11,
                 from Objects/typeobject.c:7:
In function ‘Py_DECREF_MORTAL’,
    inlined from ‘PyStackRef_XCLOSE’ at ./Include/internal/pycore_stackref.h:577:9,
    inlined from ‘_PyThreadState_PopCStackRef’ at ./Include/internal/pycore_stackref.h:662:5,
    inlined from ‘vectorcall_maybe.constprop’ at Objects/typeobject.c:2956:9:
./Include/internal/pycore_object.h:481:8: warning: array subscript 0 is outside array bounds of ‘PyObject[0]’ {aka ‘struct _object[]’} [-Warray-bounds]
  481 |     if (--op->ob_refcnt == 0) {
      |        ^
Written build/lib.linux-x86_64-3.14/_sysconfigdata__linux_x86_64-linux-gnu.py
Written build/lib.linux-x86_64-3.14/_sysconfig_vars__linux_x86_64-linux-gnu.json
Checked 112 modules (34 built-in, 77 shared, 1 n/a on linux-x86_64, 0 disabled, 0 missing, 0 failed on import)

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

[vstinner]

I don't understand the warning, the function uses a pointer, it doesn't use an array:

static inline void Py_DECREF_MORTAL(PyObject *op)
{
    assert(!_Py_IsStaticImmortal(op));
    _Py_DECREF_STAT_INC();
    if (--op->ob_refcnt == 0) {
        _Py_Dealloc(op);
    }
}

[ZeroIntensity]

I think it has to do with the compiler performing the decrement on the op address, not the ob_refcnt field. It should be fixable by changing it to --(op->ob_refcnt) instead.

[picnixz]

IIRC, according to precedence rules -> is before --, so it's surprising that the compiler complains here. But it doesn't hurt putting some () to avoid warnings.

[brandtbucher]

But it doesn't hurt putting some () to avoid warnings.

I mean, this is a bug in the compiler, not in our code.

I understand adding parens as a way of silencing certain warnings about unclear operator precedence for human readers, etc. But if the compiler just doesn't understand C operator precedence, it’s just incorrect and should be fixed in the compiler.

[brandtbucher]

This looks like a bug in GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104828

It’s probably because this particular pointer is cast from an integer (_PyStackRef.bits), and it somehow breaks the compiler’s pointer analysis.

[ZeroIntensity]

I guess it's screwing with the operator precedence somehow?
FWIW, I don't see the warning on GCC 14, so it's seemingly fixed on new versions.

[brandtbucher]

No, I don’t think this has anything to do with operator precedence. It’s just the dereference (op->ob_refcnt is equivalent to op[0].ob_refcnt) that’s triggering the bug here.

Basically, as I understand it, the C compiler tries its best to keep track of what exactly you’re pointing to. Among other things, it can use this info to tell you if you’re out of bounds of an array, or if you’re accessing invalid memory.

I think the “problem” is that when we cast the bits to a pointer (which is fine, tons of programs do it without issue), it’s sort of interpreting that as actually being a pointer to memory that doesn’t “exist” (similar to trying to access NULL[0x12345678]). It seems that it models this nonexistent memory an array of size zero, so our PyObject *op is being treated sort of like PyObject op[0] (a pointer to an array of zero PyObjects). When we try to access the memory, it warns.

It’s a compiler bug, plain and simple. Looks like it’s been fixed, too. We should probably just close this as “won’t fix”.

[skirpichev]

Bisected to 67fbfb4. I would appreciate a workaround, but if it's not actual for gcc 14 - probably this not worth it.

It seems, there are no warnings on gcc-10: https://github.com/python/cpython/actions/runs/14139921809/job/39619432128