https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122571
Bug ID: 122571
Summary: LTO object are silently host-machine dependent leading
to miscompilation
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.hirsch at gin dot de
Target Milestone: ---
An LTO object file produced from a C source file on a Linux host machine is
incompatible with the "same" gcc on a Windows host machine. gcc does not
complain about objects having been generated on another host machine, leading
to possible miscompilation when such object files are involved.
As a concrete example, consider this:
float.c is a very simple program: int main() { float f = 1.0; }.
$ aarch64-linux-gnu-gcc -flto -fno-fat-lto-objects float.c -c -o float.o
$ wine aarch64-linux-gnu-gcc.exe float.o -o float
Using a debugger, or looking at the disassembly, we can see the variable gets
initialized with 0.0, not 1.0!
This can also be observed with lto-dump:
$ aarch64-linux-gnu-lto-dump float.o -dump-body=main
GIMPLE body of function: main
void main ()
{
float f;
<bb 2> :
f_1 = 1.0e+0;
return;
}
$ wine aarch64-linux-gnu-lto-dump.exe float.o -dump-body=main
GIMPLE body of function: main
void main ()
{
float f;
<bb 2> :
f_1 = 0.0e+0;
return;
}
It seems like something about the floating point representation used is
different between a Linux and a Windows machine.
I know that LTO objects between different versions of gcc are incompatible -
the tools will usually complain if attempting to work with LTO objects produced
from a different version. I don't know if this use case is intended to work -
it'd be convenient for me - but if not, then the LTO objects should likely get
some sort of field to identify the host machine with which it was produced, so
that the "same" compiler on a different host machine can complain about it
being different.
