From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5290 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Cl=C3=A9ment?= Vasseur Newsgroups: gmane.linux.lib.musl.general Subject: Re: broken gcc optimization for facilitynames Date: Fri, 20 Jun 2014 22:09:17 +0000 (UTC) Message-ID: 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 1403302192 3618 80.91.229.3 (20 Jun 2014 22:09:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Jun 2014 22:09:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5295-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 21 00:09:46 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 1Wy70D-0005nA-Dg for gllmg-musl@plane.gmane.org; Sat, 21 Jun 2014 00:09:45 +0200 Original-Received: (qmail 21861 invoked by uid 550); 20 Jun 2014 22:09:44 -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 21853 invoked from network); 20 Jun 2014 22:09:44 -0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 59 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195-154-127-44.rev.poneytelecom.eu User-Agent: slrn/1.0.1 (Linux) Xref: news.gmane.org gmane.linux.lib.musl.general:5290 Archived-At: 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. 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?