From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24770 invoked by alias); 20 Jan 2014 20:50:37 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 24752 invoked by uid 48); 20 Jan 2014 20:50:34 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/59685] ICE: in output_2305, at config/i386/sse.md:8919 with -march=bdver1 -mavx512f Date: Mon, 20 Jan 2014 20:50:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ubizjak at gmail dot com X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status bug_file_loc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg02204.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59685 Uro=C5=A1 Bizjak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED URL| |http://gcc.gnu.org/ml/gcc-p | |atches/2014-01/msg01285.htm | |l Resolution|--- |FIXED --- Comment #3 from Uro=C5=A1 Bizjak --- Fixed. >>From gcc-bugs-return-441063-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 20 20:55:30 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 26834 invoked by alias); 20 Jan 2014 20:55:30 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 26797 invoked by uid 48); 20 Jan 2014 20:55:27 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/59893] New: Use LTO for libgcc.a, libstdc++.a, etc Date: Mon, 20 Jan 2014 20:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: build, lto X-Bugzilla-Severity: enhancement X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg02205.txt.bz2 Content-length: 1454 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 Bug ID: 59893 Summary: Use LTO for libgcc.a, libstdc++.a, etc Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: build, lto Severity: enhancement Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Hello, LTO is not really a brand new, experimental and exotic option anymore. I believe that by default, on systems that support it, we should build the static target libraries that are part of gcc with -flto (and obviously -ffat-lto-objects). This should have no impact on people not using LTO (well, slightly longer bootstrap and a little bit of hard drive wasted), and people using LTO actually expect it to apply to libstdc++ when building statically. This should "solve" PR 59048 for instance where a simple std::string function is hidden in libstdc++ and we thus miss an optimization. Assuming it works, it could also help to have new/delete inlined from libsupc++, so the middle-end optimizations on malloc/free have a chance to apply. It may be as easy as adding the flags to C(XX)FLAGS_FOR_TARGET or it may be much harder (I probably should have tried it before filing this PR), but it seems we'll have to get there eventually. This is quite different from bootstrap-lto as it applies to the target, not the host.