From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36257 invoked by alias); 20 Jun 2019 11:42:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 35721 invoked by uid 89); 20 Jun 2019 11:42:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:122f53d, H*f:sk:122f53d, HTo:U*pinskia, HContent-Transfer-Encoding:8bit 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; Thu, 20 Jun 2019 11:42:51 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5EDF2AAA8; Thu, 20 Jun 2019 11:42:49 +0000 (UTC) Subject: Re: [RFC] zstd as a compression algorithm for LTO To: Thomas Koenig , Andrew Pinski , Jan Hubicka Cc: Richard Biener , Jeff Law , GCC Development , GCC Patches References: <89e98dc0-e766-ffef-da0f-263c3b284e96@suse.cz> <1BBDAEDD-9432-4B12-BA20-63A6E047FDB6@gmail.com> <20190619192954.edwdfxns3gx2gt5m@kam.mff.cuni.cz> <122f53d2-5ae0-b801-81ab-36ce69f9efda@netcologne.de> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <9417a329-c71c-4682-872c-60ff3524c47e@suse.cz> Date: Thu, 20 Jun 2019 11:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <122f53d2-5ae0-b801-81ab-36ce69f9efda@netcologne.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg01219.txt.bz2 On 6/20/19 12:58 PM, Thomas Koenig wrote: > Am 20.06.19 um 11:07 schrieb Martin Liška: >> On the contrary, decompression >> of zstd with zlib will end with: >> lto1: internal compiler error: compressed stream: data error > > Sogenerating object files on one system and trying to read them > on another system which does not happen to have a particular > library installed would lead to failure?  If that's the case, > I am not sure that this is a good way of handling things. Yes, but LTO bytecode is not supposed to be a distributable format. Martin