Re: gcc 15 "array subscript 0" warning at level -O3
От | Andres Freund |
---|---|
Тема | Re: gcc 15 "array subscript 0" warning at level -O3 |
Дата | |
Msg-id | brpeo76nq4sb3wqkwbfjmy2b6mz5zgyoshwmqcbkmmpja5ydia@iadpnczghsyq обсуждение исходный текст |
Ответ на | Re: gcc 15 "array subscript 0" warning at level -O3 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: gcc 15 "array subscript 0" warning at level -O3
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: