Red Hat Bugzilla – Bug 1475237
Bad compilation of small problem if LTO is used
Last modified: 2018-05-03 04:35:30 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.
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.