http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54752
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |i686-w64-mingw32
Status|WAITING |RESOLVED
Resolution| |WORKSFORME
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-10-01
12:46:27 UTC ---
(In reply to comment #2)
> Yes that did fix the problem.
>
> Still it would be nice if the compiler said that rather than just crash with a
> cryptic error.
Even it is usually not what you intend (linking without optimization) it is
a feature and thus your report is a real bug - I just went for the easy
workaround ;)
> Perhaps the linker should check that the same optimisations are being used for
> both compiling and linking. It could then print a useful error message to that
> effect.
There is already a bug about LTO option handling - short summary: it's not
that easy ;)
I don't see that anyone will take your LTRANS binaries and do anything
useful with them ... we'd have prefered a reduced set of preprocessed input
sources and a way to reproduce the issue with partial linking (not sure
if that works on mingw ... heh).
Thus,
gcc -c *.i $flags -flto
gcc *.o -r -nostdlibs -flto
crashing the same way (then reduce to the set of preprocessed files that
are required to make it crash). Preferably then reducing the remaining
files.
But I see you got the desired workaround, so let's move on. Closing as
WORKSFORME.
