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.