From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 286B8A0524 for ; Thu, 4 Feb 2021 11:42:03 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 181AB24069F; Thu, 4 Feb 2021 11:42:03 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id A6864240692; Thu, 4 Feb 2021 11:42:01 +0100 (CET) IronPort-SDR: QjLPiuNASvPuzVP/LQfBwLjuv1FRIqSPqk7HPjXKFDa40bzymR20rQerPr3RVD1ii5aavIw2iy nn53yctFKcGg== X-IronPort-AV: E=McAfee;i="6000,8403,9884"; a="168896591" X-IronPort-AV: E=Sophos;i="5.79,400,1602572400"; d="scan'208";a="168896591" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Feb 2021 02:42:00 -0800 IronPort-SDR: cj2leqQV7zB6Pa0adRKu6q6bx9KwssCpvTJpvAS7RKyKL1nqBxGvylqaB/zwnGsQftmJPuTIYW UqayVOTxxVFA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,400,1602572400"; d="scan'208";a="414762956" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by FMSMGA003.fm.intel.com with ESMTP; 04 Feb 2021 02:42:00 -0800 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 4 Feb 2021 02:41:59 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 4 Feb 2021 02:41:58 -0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.1713.004; Thu, 4 Feb 2021 18:41:56 +0800 From: "Zhang, Qi Z" To: Dmitry Kozlyuk , "Rong, Leyi" CC: "david.marchand@redhat.com" , "Yigit, Ferruh" , "thomas@monjalon.net" , "Richardson, Bruce" , "talshn@nvidia.com" , "Kadam, Pallavi" , "Menon, Ranjit" , "Xing, Beilei" , "aconole@redhat.com" , "dev@dpdk.org" , "ci@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2] net/i40e: fix avx code error on MinGW Thread-Index: AQHW+XMy9xmw58jmNEa7ibqwkamwB6pE93sAgALaR+A= Date: Thu, 4 Feb 2021 10:41:56 +0000 Message-ID: <5ec7623cbb604753bb70fa9f4b0a7c3a@intel.com> References: <20210202090639.83164-1-leyi.rong@intel.com> <20210202143258.108477-1-leyi.rong@intel.com> <20210203020758.12cd8089@sovereign> In-Reply-To: <20210203020758.12cd8089@sovereign> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-ci] [dpdk-dev] [PATCH v2] net/i40e: fix avx code error on MinGW X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org Sender: "ci" > -----Original Message----- > From: Dmitry Kozlyuk > Sent: Wednesday, February 3, 2021 7:08 AM > To: Rong, Leyi > Cc: david.marchand@redhat.com; Zhang, Qi Z ; Yigit, > Ferruh ; thomas@monjalon.net; Richardson, Bruce > ; talshn@nvidia.com; Kadam, Pallavi > ; Menon, Ranjit ; Xing, > Beilei ; aconole@redhat.com; dev@dpdk.org; > ci@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: fix avx code error on MinGW >=20 > On Tue, 2 Feb 2021 22:32:58 +0800, Leyi Rong wrote: > > Adds extra cflags '-fno-asynchronous-unwind-tables' > > to avoid the MinGW build error: > > Error: invalid register for .seh_savexmm > > > > Fixes: 5c38c33f7880 ("net/i40e: disable AVX512 with MinGW") > > > > Signed-off-by: Leyi Rong >=20 > Tested-by: Dmitry Kozlyuk >=20 > Re: -fno-asynchronous-unwind-tables, when cross-compiling from Linux, I > observe bit-to-bit identical i40e_rxtx_vec_avx512.c.obj. My guess it that= this > option somehow affects GCC inlining heuristics. Similar issue existed in > librte_acl (at least a year ago win GCC 6, I believe), where GCC generate= d > incorrect code unless certain functions had been inlined (caught by test = app). > No an AVX expert, just my 2c. Applied to dpdk-next-net-intel. Thanks Qi