Red Hat Bugzilla – Bug 1475237
Bad compilation of small problem if LTO is used
Last modified: 2017-08-17 07:18:06 EDT
Description of problem:
Trying to narrow down an issue I cannot compile and run a really small program
std::cout << std::endl;
Trying to compile with
x86_64-w64-mingw32-g++ -flto -fwhole-program -O2 -g -pipe -Wall -static -Wl,--subsystem,console -o test.exe test.cpp
It compiles without any warnings but when executed it crashes.
Maybe the problem is related to bug #1455137.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. compile the test program with options specified
2. execute the compiled program (even with wine)
An empty line is printed with no crash
Maybe related to bug #1455137
Removing -static and/or -flto make the program works correctly.
Sorry, I don't think we have anyone with compiler internals knowledge looking at mingw bugs. Can you file this upstream where it is likely to get more attention, please? I'm happy to backport fixes once it's resolved upstream.
(In reply to Kalev Lember from comment #2)
> Sorry, I don't think we have anyone with compiler internals knowledge
> looking at mingw bugs. Can you file this upstream where it is likely to get
> more attention, please? I'm happy to backport fixes once it's resolved
I opened a bug to MinGW time ago but they closed the bug saying to open to the specific distro. Where should I open this bug then?
Upstream gcc maybe? Not sure where the issue exactly is.
Do you have a link to the upstream MinGW bug that was closed?
The original MinGW bug was at https://sourceforge.net/p/mingw/bugs/2346/.
Could be either gcc or binutils but being -static and -flto gcc options I would suspect gcc. I'll open a bug to them, thanks
Kai, any known regression with lto?
Somebody suggested that -flto and -fwhole-program do not play well together, but the issue happens also removing the -fwhole-program, that is even the command
x86_64-w64-mingw32-g++ -flto -O2 -g -pipe -Wall -static -Wl,--subsystem,console -o test.exe test.cpp
cause the issue.
I don't know how easy would be to try to "git blame" (or something similar) this issue. The Epel 7 mock (older than Fedora 25) does not have this issue.
Opened a bug to gcc, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879.