Bug 1475237 - Bad compilation of small problem if LTO is used [NEEDINFO]
Bad compilation of small problem if LTO is used
Status: NEW
Product: Fedora
Classification: Fedora
Component: mingw-gcc (Show other bugs)
26
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kalev Lember
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-26 05:17 EDT by Frediano Ziglio
Modified: 2017-08-17 07:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
marcandre.lureau: needinfo? (ktietz)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1455137 None None None 2017-07-26 05:17 EDT

  None (edit)
Description Frediano Ziglio 2017-07-26 05:17:25 EDT
Description of problem:
Trying to narrow down an issue I cannot compile and run a really small program
like

#include <iostream>

int main()
{
    std::cout << std::endl;
    return 0;
}

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):
mingw64-binutils-2.27-2.fc26.x86_64
mingw64-gcc-c++-7.1.0-1.fc26.x86_64
mingw64-headers-5.0.2-1.fc26.noarch


How reproducible:
Always


Steps to Reproduce:
1. compile the test program with options specified
2. execute the compiled program (even with wine)

Actual results:
Crash


Expected results:
An empty line is printed with no crash


Additional info:
Maybe related to bug #1455137
Comment 1 Frediano Ziglio 2017-07-26 05:21:06 EDT
Removing -static and/or -flto make the program works correctly.
Comment 2 Kalev Lember 2017-07-26 05:27:54 EDT
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.
Comment 3 Frediano Ziglio 2017-07-26 06:10:09 EDT
(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
> upstream.

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?
Comment 4 Kalev Lember 2017-07-26 06:13:11 EDT
Upstream gcc maybe? Not sure where the issue exactly is.

Do you have a link to the upstream MinGW bug that was closed?
Comment 5 Frediano Ziglio 2017-07-26 06:21:12 EDT
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
Comment 6 Marc-Andre Lureau 2017-07-26 07:16:57 EDT
Kai, any known regression with lto?
Comment 7 Frediano Ziglio 2017-07-26 10:12:18 EDT
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.
Comment 8 Frediano Ziglio 2017-08-17 07:18:06 EDT
Opened a bug to gcc, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879.

Note You need to log in before you can comment on or make changes to this bug.