[Bug lto/106177] New: LTO interoperability Linux/Windows

[Bug lto/106177] New: LTO interoperability Linux/Windows

[clyon at gcc dot gnu.org]

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?

[Bug lto/106177] LTO interoperability Linux/Windows

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There might be another bug which talks about host compatibility for the lto.

[Bug lto/106177] LTO interoperability Linux/Windows

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
dup

*** This bug has been marked as a duplicate of bug 41526 ***

[Bug lto/106177] LTO interoperability Linux/Windows

[richard at weickelt dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177

Richard Weickelt <richard at weickelt dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard at weickelt dot de

--- Comment #3 from Richard Weickelt <richard at weickelt dot de> ---
@Christophe Lyon, 

my use-case is that vendor A provides a binary blob of a library to vendor B.
Both A and B ensure that they use the same toolchain version, but the
developers involved use different host operating systems. LTO is a valuable
feature for us because it shrinks our binaries by 25%. Space is precious on
small MCUs.

[Bug lto/106177] LTO interoperability Linux/Windows

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177

--- Comment #4 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(In reply to Richard Weickelt from comment #3)
> @Christophe Lyon, 
> 
> my use-case is that vendor A provides a binary blob of a library to vendor
> B. Both A and B ensure that they use the same toolchain version, but the
> developers involved use different host operating systems. LTO is a valuable
> feature for us because it shrinks our binaries by 25%. Space is precious on
> small MCUs.

Thanks for the clarification, sorry that it won't be fixed soon :-(