From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3788 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Warning: gcc 4.8.x may miscompile musl 0.9.12; workaround Date: Wed, 31 Jul 2013 20:27:56 -0400 Message-ID: <20130801002756.GA20164@brightrain.aerifal.cx> 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 1375316898 13813 80.91.229.3 (1 Aug 2013 00:28:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2013 00:28:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3792-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 01 02:28:21 2013 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 1V4gkf-00084D-Lf for gllmg-musl@plane.gmane.org; Thu, 01 Aug 2013 02:28:21 +0200 Original-Received: (qmail 9678 invoked by uid 550); 1 Aug 2013 00:28:18 -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 9592 invoked from network); 1 Aug 2013 00:28:09 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3788 Archived-At: Hi, In connection to the discussion on ARM memcpy and GCC generating an infinite-self-recursive memcpy, I've now had at least one report of the issue affecting memset too. The relevant GCC ticket is: http://gcc.gnu.org/bugzilla//show_bug.cgi?id=56888 The problem occurred with GCC 4.8.1 on x86_64. I'm not sure which archs are affected, but as memset is a widely-used function, you'll know right away if you are affected. The problem seems to coincide with commit a80847d86a8865a78fdbebe7f9e2533f7a74e010, which added the ability (enabled by default) to compile certain parts of musl selectively with the -O3 optimization level; string functions are included by default. Passing --enable-optimize=fast to configure is an easy workaround for the problem. Another solution may be to add custom CFLAGS containing -fno-tree-loop-distribute-patterns as suggested in the GCC tracker thread. Note that earlier versions of musl are also affected if you manually enable -O3. This will definitely be fixed in the next release, even though it's really a GCC bug. Rich