Your work-around works for me too.
I see this with gcc 10.1, as shipped with Fedora 32, when compiling at -O2 and above:
<code>
$ gcc -v
Using built-in specs.
COLLECT_GCC=/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
$ $ gcc -O2 -c sqlite3.c
sqlite3.c: In function ‘sqlite3SelectNew’:
sqlite3.c:128048:10: warning: function may return address of local variable [-Wreturn-local-addr]
128048 | return pNew;
| ^~~~
sqlite3.c:128008:10: note: declared here
128008 | Select standin;
| ^~~~~~~
</code>
This was with sqlite-amalgamation-3310100, but fixed by your work-around at -O2 and -Wall -O3.
Note that I did try other workarounds, but couldn't get any to work.
Specifically I think the problem in the original code is that gcc can't track <code>pParse->db->mallocFailed</code>, either having to assume it could be aliased or modified by intermediate function calls.
Replacing the condition above the call to <code>clearSelect()</code> with <code>if ( `pNew==&standin || pParse->db->mallocFailed` )</code> should be robust (and cheap), but still doesn't fix the warning .
I'm not sure how much overhead your workaround adds (it looks fairly cheap to my eyes, but I am not a compiler!) but I'd guess the warning will become a lot more prevalent now GCC 10 is shipping with distros.