From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 1AFFF8E8A for ; Tue, 24 Nov 2015 18:58:17 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP; 24 Nov 2015 09:58:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,339,1444719600"; d="scan'208";a="858878424" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga002.fm.intel.com with ESMTP; 24 Nov 2015 09:58:15 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.203]) by IRSMSX152.ger.corp.intel.com ([169.254.6.143]) with mapi id 14.03.0248.002; Tue, 24 Nov 2015 17:58:14 +0000 From: "Ananyev, Konstantin" To: "Mrzyglod, DanielX T" Thread-Topic: [dpdk-dev] [PATCH v2] net: fix build with gcc 4.4.7 and strict aliasing Thread-Index: AQHRJtXlKbyCe5wuP02Xe5Mg2+ADap6rdJGg Date: Tue, 24 Nov 2015 17:58:14 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836ACBC89@irsmsx105.ger.corp.intel.com> References: <1448377959-4440-1-git-send-email-danielx.t.mrzyglod@intel.com> <1448382678-6060-1-git-send-email-danielx.t.mrzyglod@intel.com> <1448382678-6060-2-git-send-email-danielx.t.mrzyglod@intel.com> In-Reply-To: <1448382678-6060-2-git-send-email-danielx.t.mrzyglod@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2] net: fix build with gcc 4.4.7 and strict aliasing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 17:58:18 -0000 Hi Daniel, So for my own curiosity: what went wrong here? Did compiler avoid to generate a code for while {} loop? Or something else? BTW, it is an internal function, so instead of introducing new typedef, we can just change the type of buf? Let say to uint8_t *? >>From gcc manual page: " A character type may alias any other type." Would that work? Konstantin > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Daniel Mrzyglod > Sent: Tuesday, November 24, 2015 4:31 PM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH v2] net: fix build with gcc 4.4.7 and strict a= liasing >=20 > This fix is for IPv6 checksum offload error on RHEL65. > Any optimalisation above -O0 provide error in IPv6 checksum > flag "-fstrict-aliasing" is default for optimalisation above -O0. >=20 > Fixes: 2b039d5f20a3 ("net: fix build with gcc 4.4.7 and strict aliasing") >=20 > Signed-off-by: Daniel Mrzyglod > --- > lib/librte_net/rte_ip.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h > index 71c519a..5b7554a 100644 > --- a/lib/librte_net/rte_ip.h > +++ b/lib/librte_net/rte_ip.h > @@ -169,7 +169,8 @@ __rte_raw_cksum(const void *buf, size_t len, uint32_t= sum) > { > /* workaround gcc strict-aliasing warning */ > uintptr_t ptr =3D (uintptr_t)buf; > - const uint16_t *u16 =3D (const uint16_t *)ptr; > + typedef uint16_t __attribute__((__may_alias__)) u16_p; > + const u16_p *u16 =3D (const u16_p *)ptr; >=20 > while (len >=3D (sizeof(*u16) * 4)) { > sum +=3D u16[0]; > -- > 2.5.0