From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1711 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: build musl with clang Date: Fri, 24 Aug 2012 02:06:11 -0400 Message-ID: <20120824060611.GX27715@brightrain.aerifal.cx> References: <5035E16E.50004@gmail.com> <20120823122414.GM27715@brightrain.aerifal.cx> <50362C19.5080509@gmail.com> <20120823175545.GQ27715@brightrain.aerifal.cx> <5037181B.9050508@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1345788277 22806 80.91.229.3 (24 Aug 2012 06:04:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Aug 2012 06:04:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1712-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 24 08:04:38 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T4n0X-0003KL-Nq for gllmg-musl@plane.gmane.org; Fri, 24 Aug 2012 08:04:37 +0200 Original-Received: (qmail 25821 invoked by uid 550); 24 Aug 2012 06:04:35 -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 25810 invoked from network); 24 Aug 2012 06:04:35 -0000 Content-Disposition: inline In-Reply-To: <5037181B.9050508@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1711 Archived-At: On Fri, Aug 24, 2012 at 11:58:51AM +0600, agent wrote: > 23.08.2012 23:55, Rich Felker пишет: > >The bug is that clang assumes the memory returned from malloc has > >indeterminate contents, which is only a valid assumption on a hosted > >implementation. On a freestanding one, malloc is just another ordinary > >function with no special semantics. Anyway, based on the wrong > >assumption, it optimizes out the zero-fill code that's of the form > > > >for (i=0; i > > >I am not willing to remove the if, because it serves a valuable > >purpose: it avoids writing to pages that are already all-zero, which > >in turn reduces swap pressure/dirty pages. > > > >Rich > even if it assumes the memory has indeterminate contents, > indeterminate isn't zero so i feel there is no real reason to wipe > the whole cycle out only because of if statement -- malloc does not > have to (and should not) zero fill the returned memory. Any use of indeterminate values results in UB, so the compiler would be just as free to omit no code at all for the function on a hosted implementation. Rich