From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9065 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: string word-at-a-time and atomic.h FAQ on twitter Date: Wed, 6 Jan 2016 03:56:07 +0100 Message-ID: <20160106025607.GM23362@port70.net> References: <20160105164640.GL23362@port70.net> <20160105175040.GA238@brightrain.aerifal.cx> <568C5436.8040100@nicta.com.au> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452048987 23629 80.91.229.3 (6 Jan 2016 02:56:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jan 2016 02:56:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9078-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 06 03:56:22 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aGeGs-0007FM-4q for gllmg-musl@m.gmane.org; Wed, 06 Jan 2016 03:56:22 +0100 Original-Received: (qmail 15538 invoked by uid 550); 6 Jan 2016 02:56:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15517 invoked from network); 6 Jan 2016 02:56:19 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <568C5436.8040100@nicta.com.au> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9065 Archived-At: * Matthew Fernandez [2016-01-06 10:39:34 +1100]: > On 06/01/16 04:50, Rich Felker wrote: > >On Tue, Jan 05, 2016 at 05:46:41PM +0100, Szabolcs Nagy wrote: > >>... however i find lto a > >>weak excuse to rewrite strlen in asm for all targets since lto > >>of libc is still not practical ... > > This is an interesting comment; would you mind expanding on this a little? Though we don't do it > regularly, we have used LTO on Musl C in the past. I am not aware of any Musl-specific issues we > encountered, though it's entirely possible our build contained latent bugs. two things: 1) does not give the expected improvements (smaller, faster) on code that's factored well. 2) wrong code genertion (because of lto implementation bugs, or because of invalid c code) i think we saw issues around file scope inline asm, we speculated about issues around fenv access because the compilers don't model that correctly and early dynamic linker code. it is easy to imagine other nasty cases especially if gcc extensions are in use: they are often not carefully specified enough to have robust semantics with lto (e.g. attribute const for tls was an example where the semantics is unclear but lto makes it easier to break code if the user and compiler disagree) in short: i dont see the benefits given the risks.