https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177
Bug ID: 106177
Summary: LTO interoperability Linux/Windows
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hello,
As reported in https://bugs.linaro.org/show_bug.cgi?id=5859, when compiling C
code with gcc and -flto on a Linux host and linking the final binary on a
Windows host with exactly the same toolchain version, all float constants are
0, whereas the rest of the code seems valid. Code compiled with g++ is not
affected by this, only gcc.
Example code:
float test_float()
{
return 47.0;
}
Compilation:
arm-none-eabi-gcc -Os -flto -c test.c -o test.o
Dumping GIMPLE code on the same Linux host shows:
arm-none-eabi-lto-dump -dump-body=test_float test.o
test_float ()
{
<bb 2> [local count: 1073741824]:
return 4.7e+1;
}
Dumping GIMPLE code on a Windows host with the same toolchain release:
arm-none-eabi-lto-dump.exe -dump-body=test_float test.o
test_float ()
{
<bb 2> [local count: 1073741824]:
return 0.0e+0;
}
The original use-case is not clear to me (compiling on a Linux host, linking on
a Windows one), however I'm wondering whether LTO objects are supposed to be
interoperable in the way?
Maybe it's just a matter of how floating-point objects are encoded/decoded?
