From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5293 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: broken gcc optimization for facilitynames Date: Fri, 20 Jun 2014 20:34:48 -0400 Message-ID: <20140621003448.GD179@brightrain.aerifal.cx> References: <20140619033409.GK179@brightrain.aerifal.cx> 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 1403310908 8112 80.91.229.3 (21 Jun 2014 00:35:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Jun 2014 00:35:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5298-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 21 02:35:01 2014 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 1Wy9Gn-00071z-Dn for gllmg-musl@plane.gmane.org; Sat, 21 Jun 2014 02:35:01 +0200 Original-Received: (qmail 28360 invoked by uid 550); 21 Jun 2014 00:35:00 -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 28349 invoked from network); 21 Jun 2014 00:35:00 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5293 Archived-At: On Fri, Jun 20, 2014 at 10:09:17PM +0000, Clément Vasseur wrote: > On 2014-06-19, Rich Felker wrote: > > On Wed, Jun 18, 2014 at 04:31:58PM +0000, Clément Vasseur wrote: > >> Hello, > >> > >> I might have found a gcc code generation problem with the facilitynames > >> implementation used in musl. See the following reduced test case: > >> > >> $ cat test-facilitynames.c > >> #define SYSLOG_NAMES > >> #include > >> int main(void) > >> { > >> for (int i = 0; facilitynames[i].c_name; i++) > >> if (facilitynames[i].c_name) > >> return facilitynames[i].c_val; > >> } > >> > >> $ musl-gcc -std=gnu99 -O1 test-facilitynames.c && ./a.out; echo $? > >> 32 > >> > >> $ musl-gcc -std=gnu99 -O2 test-facilitynames.c && ./a.out; echo $? > >> 1 > >> > >> I see similar results with gcc versions 4.6.1, 4.8.3 and 4.9.0 (with a > >> different return value with -O2). > > > > I can verify that I see this one on gcc 4.7.3. I don't see any UB in > > the code so I'm pretty sure this is a gcc bug. > > > > Note that we should really fix this horrible definition of > > facilitynames (it bloats busybox by quite a bit), but it's a nice > > demonstration of the gcc bug which we should also report and try to > > get fixed.. > > > > Can you make a self-contained test case (copy the macros from musl's > > syslog.h into the source file) and file a gcc bug report? > > I made some progress towards a standalone test case. Here it is: > > struct s1 { int v; }; > struct s2 { int v; }; > > #define a ((struct s2 *)(struct s1 []){{ 42 }}) > > int main(void) > { > for (int i = 0; a[i].v; i++) > if (a[i].v) > return a[i].v; > } > > I also found out which optimization flag causes the broken output, it's > -fstrict-aliasing. I guess the issue here is whether casting `struct s1 > []` to `struct s2 *` violates the strict aliasing rules or not. Indeed, > compiling with -Wstrict-aliasing=1 shows a warning at this location. It's indeed an aliasing violation. And I don't see what the point of it was in the first place. Whether c_name has type char * or const char * has no bearing on whether the data can reside in .text/.rodata. > Can someone pinpoint the exact location in the ISO C spec where there is > an explanation about the aliasing rules with this kind of pointer > compatibility? C99 6.5 paragraph 7. Rich