From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60846 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756278AbdKCODs (ORCPT ); Fri, 3 Nov 2017 10:03:48 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA3E3iMu015933 for ; Fri, 3 Nov 2017 10:03:48 -0400 Received: from e17.ny.us.ibm.com (e17.ny.us.ibm.com [129.33.205.207]) by mx0a-001b2d01.pphosted.com with ESMTP id 2e0ssqgevh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 03 Nov 2017 10:03:47 -0400 Received: from localhost by e17.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 3 Nov 2017 10:03:45 -0400 Date: Fri, 3 Nov 2017 07:03:42 -0700 From: "Paul E. McKenney" Subject: Re: Invalid compilation without -fno-strict-aliasing Reply-To: paulmck@linux.vnet.ibm.com References: <20171103122719.GH3624@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-Id: <20171103140342.GK3624@linux.vnet.ibm.com> Sender: perfbook-owner@vger.kernel.org List-ID: To: Yubin Ruan Cc: perfbook@vger.kernel.org On Fri, Nov 03, 2017 at 09:33:48PM +0800, Yubin Ruan wrote: > Thanks Paul, > > 2017-11-03 20:27 GMT+08:00 Paul E. McKenney : > > On Fri, Nov 03, 2017 at 09:54:15AM +0800, Yubin Ruan wrote: > >> Does anyone have any idea why this thread > >> > >> https://lkml.org/lkml/2003/2/25/270 > > > > Hmmm... This is quite the blast from the past. Compilers have changed > > a bit in the last 14 years. Nevertheles... > > Unfortunately I got several old servers with GCC 3.x so I have to keep > an eye on these things (and worse, I am one of those guys who like to > home-brew some locking primitives...) > > >> is related to strict-aliasing? To me, a compiler barrier like this will fix it: > >> > >> if((stream + event_len) < ends) { > >> iwe->len = event_len; > >> barrier(); > >> memcpy(stream, (char *) iwe, event_len); > >> stream += event_len; > >> } > > > > As with many bugs, there are a number of ways to fix this one. I suggest taking > > a look at the documentation for -no-strict-alias. This stackoverflow URL might > > not be a bad place to start: > > > > https://stackoverflow.com/questions/23848188/strict-aliasing-rule-and-char-pointers > > Basically I understand what aliasing means (for the C/C++ Languages) > and I know what a strict aliasing rule it is. I just cannot see why a > strict aliasing rule will cause this reordering problem... OK. Then please tell me why exactly you believe that strict aliasing does not allow the compiler to reverse the order of the first two statements in the body of the above "if" statement. Thanx, Paul