From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-441144-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22728 invoked by alias); 21 Jan 2014 19:06:05 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 22689 invoked by uid 48); 21 Jan 2014 19:05:59 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
Date: Tue, 21 Jan 2014 19:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
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:
Message-ID: <bug-59893-4-GEaitBiAH3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59893-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59893-4@http.gcc.gnu.org/bugzilla/>
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/msg02286.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
Joseph, thank you for those precisions, I hadn't realized the width of the
problem. Similarly, on my Debian multiarch machine, when I cross-compile for
arm, I use a libgcc.a that was built natively on arm, so that would break as
well.

I believe LTO streams come with a format version, and gcc checks that it
understands this version before proceeding (and gives an error otherwise).
Maybe it could also embed the host triple and check that it is the same. And
possibly downgrade the errors to warnings as long as we have a fat object and
can fall back to regular linking.

I understand this all makes it too early for LTO by default.

I guess a configure option --enable-lto-libraries that defaults to "no" would
still make sense, with suitably dire warnings in the doc.