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?