From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: gcc 15 "array subscript 0" warning at level -O3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1985045.1745602635.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Apr 2025 13:37:15 -0400
Message-ID: <1985046.1745602635@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1985046.1745602635%40sss.pgh.pa.us>
Precedence: bulk

Whilst poking at Erik Rijkers' nearby report, I found that
Fedora 42's gcc 15.0.1 will produce this complaint if you
select optimization level -O3:


In file included from ../../../../src/include/access/htup_details.h:22,
                 from pl_exec.c:21:
In function 'assign_simple_var',
    inlined from 'exec_set_found' at pl_exec.c:8609:2:
../../../../src/include/varatt.h:230:36: warning: array subscript 0 is out=
side array bounds of 'char[0]' [-Warray-bounds=3D]
  230 |         (((varattrib_1b_e *) (PTR))->va_tag)
      |                                    ^
../../../../src/include/varatt.h:94:12: note: in definition of macro 'VART=
AG_IS_EXPANDED'
   94 |         (((tag) & ~1) =3D=3D VARTAG_EXPANDED_RO)
      |            ^~~
../../../../src/include/varatt.h:284:57: note: in expansion of macro 'VART=
AG_1B_E'
  284 | #define VARTAG_EXTERNAL(PTR)                            VARTAG_1B_=
E(PTR)
      |                                                         ^~~~~~~~~~=
~
../../../../src/include/varatt.h:301:57: note: in expansion of macro 'VART=
AG_EXTERNAL'
  301 |         (VARATT_IS_EXTERNAL(PTR) && !VARTAG_IS_EXPANDED(VARTAG_EXT=
ERNAL(PTR)))
      |                                                         ^~~~~~~~~~=
~~~~~
pl_exec.c:8797:17: note: in expansion of macro 'VARATT_IS_EXTERNAL_NON_EXP=
ANDED'
 8797 |                 VARATT_IS_EXTERNAL_NON_EXPANDED(DatumGetPointer(ne=
wvalue)))
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'exec_set_found':
cc1: note: source object is likely at address zero


Buildfarm member serinus has been producing the identical warning for
some time.  I'd been ignoring that because it runs "experimental gcc",
but I guess the experiment has leaked out to production distros.

What seems to be happening here is that after inlining
assign_simple_var into exec_set_found, the compiler decides that
"newvalue" might be zero (since it's a BoolGetDatum result),
and then it warns -- in a rather strange way -- about the
potential null dereference.  The dereference is not reachable
because of the preceding "var->datatype->typlen =3D=3D -1" check,
but that's not stopping the optimizer from bitching.

I experimented with modifying exec_set_found thus:

	var =3D (PLpgSQL_var *) (estate->datums[estate->found_varno]);
+	Assert(var->datatype->typlen =3D=3D 1);
	assign_simple_var(estate, var, BoolGetDatum(state), false, false);

which should be OK since we're expecting the "found" variable to
be boolean.  That does silence the warning, but of course only
in --enable-cassert builds.

Anybody have an idea about how to silence it more effectively?
There are going to be more people seeing this as gcc 15 propagates.

			regards, tom lane