GCC 10.0.1 on PPC64LE Fedora Rawhide LTO 3.x buildbot:
https://buildbot.python.org/all/#/builders/351/builds/406

Objects/longobject.c: In function ‘_PyLong_Frexp’:
Objects/longobject.c:2928:33: warning: ‘x_digits[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 2928 |                     x_digits[0] |= 1;
      |                                 ^~

In function ‘assemble_lnotab’,
    inlined from ‘assemble_emit’ at Python/compile.c:5709:25,
    inlined from ‘assemble’ at Python/compile.c:6048:18:
Python/compile.c:5663:19: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
 5663 |         *lnotab++ = k;
      |         ~~~~~~~~~~^~~

Did you add any options to the ./configure call for cpython?  What were they?

Andy Lester:
> Did you add any options to the ./configure call for cpython?  What were they?

I reported warnings that I saw on a buildbot build.

Extract of https://buildbot.python.org/all/#/builders/351/builds/406.

configure step:

    ./configure --prefix '$(PWD)/target' --with-lto

test.pythoninfo of the build says:

CC.version: gcc (GCC) 10.0.1 20200420 (Red Hat 10.0.1-0.12)

sysconfig[CCSHARED]: -fPIC
sysconfig[CC]: gcc -pthread
sysconfig[CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[CONFIG_ARGS]: '--prefix' '/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-ppc64le.lto/build/target' '--with-lto'
sysconfig[OPT]: -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[PY_CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
sysconfig[PY_CFLAGS_NODIST]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal
sysconfig[PY_CORE_LDFLAGS]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g
sysconfig[PY_LDFLAGS_NODIST]: -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g
sysconfig[PY_STDMODULE_CFLAGS]: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I. -I./Include

I'm fairly sure that that's a false positive for `longobject.c`. Do you know of a non-intrusive way to silence the warning?

As to _why_ it's a false positive: at that point in the code, assuming 30-bit limbs and an IEEE 754 binary64 "double", we have (using Python notation for floor division)

    a_size == 1 + (a_bits - 1) // 30

and

    shift_digits == (a_bits - 55) // 30

from which it's clear that

    shift_digits <= (a_bits - 1) // 30 < a_size

so a_size - shift_digits is always strictly positive.

The above doesn't depend on the precise values 55 and 30 - any other positive values would have worked, so even with 15-bit digits and some other double format with fewer bits, we still have "shift_digits < a_size".

And now since the v_rshift call writes "a_size - shift_digits" digits to x, we're guaranteed that at least one digit is written, so `x[0]` is not uninitialised.

@mark.dickinson @vstinner

I'd like to suggest this change.
There was no performance impact on my local machine.

--- a/Objects/longobject.c
+++ b/Objects/longobject.c
@@ -2852,7 +2852,8 @@ _PyLong_Frexp(PyLongObject *a, Py_ssize_t *e)
 {
     Py_ssize_t a_size, a_bits, shift_digits, shift_bits, x_size;
     /* See below for why x_digits is always large enough. */
-    digit rem, x_digits[2 + (DBL_MANT_DIG + 1) / PyLong_SHIFT];
+    digit rem;
+    digit x_digits[2 + (DBL_MANT_DIG + 1) / PyLong_SHIFT] = {0,};
     double dx;
     /* Correction term for round-half-to-even rounding.  For a digit x,
        "x + half_even_correction[x & 7]" gives x rounded to the nearest
@@ -2903,8 +2904,6 @@ _PyLong_Frexp(PyLongObject *a, Py_ssize_t *e)
         shift_digits = (DBL_MANT_DIG + 2 - a_bits) / PyLong_SHIFT;
         shift_bits = (DBL_MANT_DIG + 2 - a_bits) % PyLong_SHIFT;
         x_size = 0;
-        while (x_size < shift_digits)
-            x_digits[x_size++] = 0;
         rem = v_lshift(x_digits + x_size, a->ob_digit, a_size,
                        (int)shift_bits);
         x_size += a_size;

New changeset b88cd585d36d6285a5aeb0b6fdb70c134062181e by Dong-hee Na in branch 'master':
bpo-40455: Remove gcc10 warning about x_digits (#19852)
https://github.com/python/cpython/commit/b88cd585d36d6285a5aeb0b6fdb70c134062181e

For anyone following along, note that the PR above is different than the original suggestion.  The PR correctly sets x_size, not leaving it zero.

There are still warnings on compile.c:
https://buildbot.python.org/all/#/builders/448/builds/130

Python/compile.c:5660:19: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
Python/compile.c:5660: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
Python/compile.c:5660: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

Hi, I've on my Debian (testing) the reported warning:

In function ‘assemble_lnotab’,
    inlined from ‘assemble_emit’ at Python/compile.c:5706:25,
    inlined from ‘assemble’ at Python/compile.c:6048:18:
Python/compile.c:5660:19: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
 5660 |         *lnotab++ = k;
      |      


gcc --version          
gcc (Debian 10.2.0-5) 10.2.0
Copyright (C) 2020 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.

New changeset 86e322f1412be6c5a6c8fa8e73af68b99c42bb18 by Pablo Galindo in branch 'master':
bpo-40455: Fix gcc10+ warning about writing into a section of offset 0 (GH-24384)
https://github.com/python/cpython/commit/86e322f1412be6c5a6c8fa8e73af68b99c42bb18

Thank you Pablo!!