Subject: Re: gcc 15 "array subscript 0" warning at level -O3

From: Andres Freund <[email-masked]>
Date: Wed, 4 Jun 2025 15:00:03 -0400

Hi,

On 2025-04-25 15:58:29 -0400, Andres Freund wrote:
> On 2025-04-25 13:37:15 -0400, Tom Lane wrote:
> > 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.
> 
> I don't think it actually is complaining about a null dereference - it thinks
> we're interpreting a boolean as a pointer (for which it obviously is not wide
> enough)
> 
> 
> > The dereference is not reachable
> > because of the preceding "var->datatype->typlen == -1" check,
> > but that's not stopping the optimizer from bitching.
> 
> > I experimented with modifying exec_set_found thus:
> > 
> > 	var = (PLpgSQL_var *) (estate->datums[estate->found_varno]);
> > +	Assert(var->datatype->typlen == 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.
> 
> One way to address this is outlined here:
> 
> https://postgr.es/m/20230316172818.x6375uvheom3ibt2%40awork3.anarazel.de
> https://postgr.es/m/20240207203138.sknifhlppdtgtxnk%40awork3.anarazel.de
> 
> I've been wondering about adding wrapping something like that in a
> pg_assume(expr) or such.

I've been once more annoyed by this warning. Here's a prototype for the
approach outlined above.

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Thu, 05 Jun 2025 15:50:48 -0400

> I've been once more annoyed by this warning. Here's a prototype for the

Looks plausible by eyeball.  I did notice a typo in the comment:

+ * pg_assume(expr) stats that we assume `expr` to evaluate to true. In assert

s/stats/states/, I think you meant.

			regards, tom lane

---

From: jian he <[email-masked]>
Date: Wed, 2 Jul 2025 22:13:17 +0800

> I've been once more annoyed by this warning. Here's a prototype for the

I can confirm the warning disappears when using gcc-14.0 compile
source code with the attached patch.
I didn't review it though.
I didn’t find this in the CommitFest, so I added an entry [1] to make sure it
doesn’t get forgotten...

[1]: https://commitfest.postgresql.org/patch/5888/

---

From: Andres Freund <[email-masked]>
Date: Wed, 9 Jul 2025 19:20:20 -0400

Hi,

> s/stats/states/, I think you meant.

Thanks.  I pushed it with that tweak and a bit of minor comment burnishing.
Glad to see the last of that warning.

Greetings,

Andres Freund

---

From: Andres Freund <[email-masked]>
Date: Wed, 9 Jul 2025 19:21:29 -0400

Hi,

> I didn’t find this in the CommitFest, so I added an entry [1] to make sure it

Thanks. Pushed it now and closed the CF entry.

Greetings,

Andres Freund