From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59727 invoked by alias); 22 Jul 2019 14:25:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 59670 invoked by uid 89); 22 Jul 2019 14:25:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=hats, shipped, planning, great! X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Jul 2019 14:25:40 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 267F1ABE7; Mon, 22 Jul 2019 14:25:38 +0000 (UTC) Subject: Re: Can LTO minor version be updated in backward compatible way ? To: Jeff Law , Andi Kleen , Romain Geissler Cc: gcc@gcc.gnu.org References: <87ftn4in6x.fsf@linux.intel.com> <71c86eab-4178-e841-f968-b4425f851dd3@redhat.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <3535d8a9-8fed-baa9-be7e-9eecada5a9e8@suse.cz> Date: Mon, 22 Jul 2019 14:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <71c86eab-4178-e841-f968-b4425f851dd3@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00149.txt.bz2 On 7/17/19 8:10 PM, Jeff Law wrote: > On 7/17/19 11:29 AM, Andi Kleen wrote: >> Romain Geissler writes: >>> >>> I have no idea of the LTO format and if indeed it can easily be updated >>> in a backward compatible way. But I would say it would be nice if it >>> could, and would allow adoption for projects spread on many teams >>> depending on each others and unable to re-build everything at each >>> toolchain update. >> >> Right now any change to an compiler option breaks the LTO format >> in subtle ways. In fact even the minor changes that are currently >> done are not frequent enough to catch all such cases. >> >> So it's unlikely to really work. > Right and stable LTO bytecode really isn't on the radar at this time. > > IMHO it's more important right now to start pushing LTO into the > mainstream for the binaries shipped by the vendors (and stripping the > LTO bits out of any static libraries/.o's shipped by the vendors). > > > SuSE's announcement today is quite ironic. Why and what is ironic about it? > Red Hat's toolchain team is > planning to propose switching to LTO by default for Fedora 32 and were > working through various details yesterday. Great! > Our proposal will almost > certainly include stripping out the LTO bits from .o's and any static > libraries. Yes, we do it as well for now. Martin > > Jeff >