Compiled attached sqlite3.c from recent SQLite release with GCC 14 and -O3 produces the following bogus (according to our analysis) warning: $ gcc-14 -O3 -c sqlite3.c In function ‘sqlite3Strlen30’, inlined from ‘sqlite3ColumnSetColl’ at sqlite3.c:115936:10: sqlite3.c:33361:28: warning: ‘strlen’ reading 1 or more bytes from a region of size 0 [-Wstringop-overread] 33361 | return 0x3fffffff & (int)strlen(z); | ^~~~~~~~~ In function ‘sqlite3ColumnSetColl’: cc1: note: source object is likely at address zero $ gcc-14 --version gcc-14 (Debian 14.1.0-1) 14.1.0 There is no such warning with GCC 13.2.0.
>Compiled attached sqlite3.c Looks like it didn't attach. Can you try again? Maybe compress it?
Ok, I couldn't attach the source file due to size limits, but you can get it from https://sqlite.org/download.html . I get this warning with the latest version, which is 3.46.0 at the time of this writing.
(In reply to Boris Kolpackov from comment #2) > Ok, I couldn't attach the source file due to size limits, but you can get it > from https://sqlite.org/download.html . I get this warning with the latest > version, which is 3.46.0 at the time of this writing. Please try compress it.
> Please try compress it. I did try with xz -9e and it was still 1.5M (the limit is 1M). I doubt any compression method will be able to shave those 50% off.
*** Bug 115702 has been marked as a duplicate of this bug. ***
The source file that causes the problem can now be downloaded from <https://sqlite.org/tmp/sqlite3-20240523.c>.
Doesn't reproduce for me on recent trunk. So maybe already fixed. The file is useful as a general run test case for the compiler though.
Ah never mind. I ran it with the wrong option with -O3 it shows the warning. Unfortunately the run time is very long so it will be difficult to minimize.
creduce minimized it to #include <string.h> char *c; void a(); int b(char *d) { return strlen(d); } void e() { long f = 1; f = b(c + f); if (c == 0) a(f); } From the one it seems to be invalid because the c global is indeed NULL. but it's hard to say if it is exactly equivalent because it will depend on the caller and the original test case had something like 30+ callers, so we don't know the exact context. Problem is that these warnings which depend on inlining should really print the inline stack for the instance that triggers the warning. I opened PR115704
-fno-thread-jumps fixes it, so it's probably a dup of PR109071 (same problem with a different warning)