From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de [89.1.8.211]) by sourceware.org (Postfix) with ESMTPS id C22243858C52; Fri, 29 Sep 2023 06:03:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C22243858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=netcologne.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=netcologne.de Received: from cc-smtpin1.netcologne.de (cc-smtpin1.netcologne.de [89.1.8.201]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 31664128A7; Fri, 29 Sep 2023 08:03:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1695967390; bh=n3EV3Q1JMsZZJ6kCHY/tQT+Cnno1Eu3CBiCmFsf8Wdw=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:From; b=kvRs8/7GDvu60dSCiQSAuY7+DsOOMAe22qAxsI7jtn2QyDD7WFwVuNmkVwQMqGSFE CL4nx1gQ6bcsqyTcc9Vegef7yrokEMeCZarFpQ8faGoKng1qNidYwSeI195fSRSWfe 8XZckD2CK5HU/dCLTRaoMJy2eMsQUlmllc30LKkY07quCCo7pBN7T18Ip4l6bVLLu6 c9yM8MkPIlnjqsXj7jjgDlv8OukfEJUD3UhtfRC/Q5AWg7xjftUX3ZyAg9Xa/RezhA dY/b/nA4e1PPaI0VdOXQKLBftefqfd3sPADXTvNEAxZjDH2mpn+OGJWxpqgF7E3njY PNuhm1JeQR4wg== Received: from [IPV6:2001:4dd7:5334:0:e2ce:83e5:efe5:1bb9] (2001-4dd7-5334-0-e2ce-83e5-efe5-1bb9.ipv6dyn.netcologne.de [IPv6:2001:4dd7:5334:0:e2ce:83e5:efe5:1bb9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin1.netcologne.de (Postfix) with ESMTPSA id 9973611D91; Fri, 29 Sep 2023 08:03:06 +0200 (CEST) Message-ID: <33907a4c-8d72-374c-498c-60df4bf350b2@netcologne.de> Date: Fri, 29 Sep 2023 08:03:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Test with an lto-build of libgfortran. Content-Language: en-US, de-DE To: Jakub Jelinek , Toon Moene Cc: gcc mailing list , gfortran References: <9e347fa4-1940-46c6-a5c9-899cf5a7ae85@moene.org> <672da73c-e5d2-4512-8ae9-1c36f14f2b97@moene.org> From: Thomas Koenig In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-NetCologne-Spam: L X-Rspamd-Action: no action X-Rspamd-Queue-Id: 9973611D91 X-Spamd-Bar: - X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Jakub, > It is worse than that, usually the LTO format changes e.g. any time any > option or parameter is added on a release branch (several times a year) and > at other times as well. Hm, that makes LTO not very well suited for libraries... > Though, admittedly GCC is the single package that actually could get away > with LTO in lib*.a libraries, at least in some packagings (if the static > libraries are in gcc specific subdirectories rather than say /usr/lib{,64} > or similar and if the packaging of gcc updates both the compiler and > corresponding static libraries in a lock-step. Because in that case LTO > in there will be always used only by the same snapshot from the release > branch and so should be compatible with the LTO in it. Maybe another approach: Instead of storing version-dependent LTO code in the *.a files, we could just store preprocessed C code there, somewhat shortened by removing whitespace, comments and unused declarations (and/or store them in compressed format). This would also allow the something like sanitizers to look into the runtime libraries, and other instrumentation. It would also be a much more extensive project, also involving modifications to the linker. Not sure how realistic that would be. Best regards Thomas