[Bug lto/55493] New: [4.8 Regression] LTO always ICEs on i686-w64-mingw32

[Bug lto/55493] New: [4.8 Regression] LTO always ICEs on i686-w64-mingw32

[fanael4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

             Bug #: 55493
           Summary: [4.8 Regression] LTO always ICEs on i686-w64-mingw32
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: fanael4@gmail.com


Revision 193777 ICEs with 

    lto1.exe: internal compiler error: cannot read LTO decls from <the object
file>

when linking with -flto on i686-w64-mingw32. This happens for all inputs, even
for "int main() { return 0; }" or "" (that is, an empty file).

 >> gcc -v
Using built-in specs.
COLLECT_GCC=C:\devel\mingw\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/devel/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.8.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../gcc-4.8-svn/configure --disable-nls
--build=i686-w64-mingw32 --disable-multilib --enable-languages=c,c++,lto
--disable-win32-registry --enable-openmp --enable-libgomp --enable-graphite
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--enable-threads=posix --disable-symvers --enable-fully-dynamic-string
--disable-libstdcxx-pch --with-arch=i686 --with-tune=generic
--enable-checking=release --disable-werror --disable-sjlj-exceptions
--prefix=/c/builds/gcc/toolchain/out --with-gmp=/c/builds/gcc/prerequisites/out
--with-mpfr=/c/builds/gcc/prerequisites/out
--with-mpc=/c/builds/gcc/prerequisites/out
--with-isl=/c/builds/gcc/prerequisites/out
--with-cloog=/c/builds/gcc/prerequisites/out
--with-libiconv-prefix=/c/builds/gcc/prerequisites/out
--with-host-libstdcxx=-lstdc++ --enable-cloog-backend=isl
Thread model: posix
gcc version 4.8.0 20121124 (experimental) (GCC)

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-w64-mingw32

[fanael4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

--- Comment #1 from fanael4 at gmail dot com 2012-11-27 16:25:58 UTC ---
Forgot to mention:

4.7.2 - works
4.8.0 r193777 - fails

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-w64-mingw32

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-w64-mingw32

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-01-07
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-07 15:25:22 UTC ---
Are you sure that you do not somehow pull in LTO objects from older releases?
Needs someone with access to $target to debug.

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[fanael4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

--- Comment #3 from Fanael <fanael4 at gmail dot com> 2013-01-09 14:19:09 UTC ---
(In reply to comment #2)
> Are you sure that you do not somehow pull in LTO objects from older releases?

Yes, happens even with -nostdlib, even on builds where I'm absolutely sure
there's no way an old LTO object could sneak in.

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktietz at gcc dot gnu.org

--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> 2013-01-15 17:38:31 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Are you sure that you do not somehow pull in LTO objects from older releases?
> 
> Yes, happens even with -nostdlib, even on builds where I'm absolutely sure
> there's no way an old LTO object could sneak in.

I can't reproduce that.  btw how are you doing linker-tests without specifying
object-code and libraries?
Nevertheless I assume that runtime is build with older-version of gcc.  It is a
bit sad that LTO doesn't tell that version is outdated.

I've tested it with gcc version from 15th of January 2012 and it works
flawless.  But I have rebuild my runtime with new version.  That is recommented
to do.

I would suggest to close that bug as WORKSFORME

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #5 from Kai Tietz <ktietz at gcc dot gnu.org> 2013-01-15 18:32:45 UTC ---
After retesting it, I close it as works for me.

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[fanael4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

--- Comment #6 from Fanael <fanael4 at gmail dot com> 2013-01-16 18:15:25 UTC ---
Oh right. Works for me too. I should've tested it more thoroughly first.

Sorry for bothering you guys.

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[fanael4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

Fanael <fanael4 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |

--- Comment #7 from Fanael <fanael4 at gmail dot com> 2013-01-18 18:45:50 UTC ---
Reopening.

The build that worked for me was a cross compiler on x86_64-unknown-linux-gnu
host. Native compiler on i686-mingw32 host still fails when trying to use LTO.
So either I'm doing something terribly wrong (I think I'm not, I built
everything from scratch with the very same compiler version this time), or
there *is* a bug.

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[vanboxem.ruben at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

Ruben Van Boxem <vanboxem.ruben at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vanboxem.ruben at gmail dot
                   |                            |com

--- Comment #8 from Ruben Van Boxem <vanboxem.ruben at gmail dot com> 2013-01-20 18:34:11 UTC ---
I can confirm that this bug is present for GCC 4.8 dated 20121221, which is
available here:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.8-unstable/i686-w64-mingw32-gcc-4.8-unstable-win32_rubenvb.7z/download

I get:

lto1.exe: internal compiler error: cannot read LTO decls from
R:\temp\ccgzHybZ.o
Please submit a full bug report,
with preprocessed source if appropriate.
See <mingw-w64-public@lists.sourceforge.net> for instructions.
lto-wrapper: g++ returned 1 exit status
m:/development/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe:
lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-08 14:58:02 UTC ---
Somebody needs to debug this.

[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

--- Comment #10 from Kai Tietz <ktietz at gcc dot gnu.org> 2013-02-12 15:27:45 UTC ---
Well, I re-tried to reproduce this issue with current 4.8 gcc version (native).
As before, I can't reproduce that issue.  Anyway I don't get what report was
actual doing differently as I did, so I will keep this bug open.
Nevertheless we had recently some changes to lto, which are affecting mingw
targets, so it might be worth that report are retrying to reproduce.

Please make sure that you aren't mixing objects with LTO-infomration of
different versions.

[Bug lto/55493] [4.8 Regression] LTO always ICEs on native i686-mingw32

[fanael4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493

Fanael <fanael4 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #11 from Fanael <fanael4 at gmail dot com> 2013-02-27 16:39:56 UTC ---
Revision 196313 appears to work.