https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124242
Bug ID: 124242
Summary: Incorrect code generated when using -m32 and -Os on
Mint Linux
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drh at sqlite dot org
Target Milestone: ---
Bug discovered during SQLite testing. A repro procedure is below. I'm sorry I
don't have a simpler test case for you - I've spent hours trying to come up
with one.
(1) Download https://sqlite.org/tmp/gcc-bug-20260225.tar.gz.
(2) Unpack in a temporary directory.
(3) gcc -g -Os -I. -m32 sqlite3.c shell.c -lpthread -lm -ldl
(4) ./a.out b2.sql
The answer should be -2251799813685249 but comes out as -1.
The problem occurs at <https://sqlite.org/src/info/401a320db40?ln=120> (seen at
line 85039 in the "sqlite3.c" file in the tarball). The value of p->u.i, which
is 0xfff7ffffffffffff gets passed down into the function as 0xffffffffffffffff.
Bit 51 changes from 0 to 1.
It all works on every other platform we test, and it works with -O0. The
problem only occurs with -m32 and optimizations enabled. The problem seems to
be similar, but not identical to, bug 96270.
Looking at the disassembly in gdb, it appears that same assembly code is used
to load p->u.i as is used to load p->u.r, 9 lines below, presumably because u.i
and u.r occupy the same storage. But the floating-point opcodes used clear set
bit 51, which if fine for floating-point values but does not work for integers,
as it causes the -2251799813685249 to change into -1.
Note that the "sqlite3.c" in the tarball above has an extra "&& 0" on the "#if"
on line 111, to disable the work-around we currently have in place. Other than
that, the "sqlite3.c", "sqlite3.h", and "shell.c" files in the tarball are
identical to what we would deliver.
