From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v3 0/2] gcc-8 build fixes Date: Tue, 3 Apr 2018 08:10:36 -0700 Message-ID: <20180403081036.4061b248@xeon-e3> References: <20180329170531.2478-1-stephen@networkplumber.org> <8988b191-30cd-a9fe-1cd2-8625c671a7fe@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org To: Ferruh Yigit Return-path: Received: from mail-pl0-f67.google.com (mail-pl0-f67.google.com [209.85.160.67]) by dpdk.org (Postfix) with ESMTP id 8E52F1B80D for ; Tue, 3 Apr 2018 17:10:44 +0200 (CEST) Received: by mail-pl0-f67.google.com with SMTP id c21-v6so5604802plz.10 for ; Tue, 03 Apr 2018 08:10:44 -0700 (PDT) In-Reply-To: <8988b191-30cd-a9fe-1cd2-8625c671a7fe@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 3 Apr 2018 10:23:43 +0100 Ferruh Yigit wrote: > On 3/29/2018 6:05 PM, Stephen Hemminger wrote: > > This fixes some of the obvious warnings found building DPDK > > with gcc-8. There still are some deeper issues in the rte_hash_table > > code; leave the fix for that up to the maintainer. > >=20 > > Stephen Hemminger (2): > > rte_mbuf: fix strncpy warnings > > rte_metrics: fix strncpy truncation warning > >=20 > > v3 > > missing SOB on 1st patch > >=20 > > v2 > > fix issues with wrong length in mbuf pool_ops > > don't need memset in metrics names > >=20 > > Stephen Hemminger (2): > > rte_mbuf: fix strncpy warnings > > rte_metrics: fix strncpy truncation warning =20 >=20 > I tried with gcc-8 [1] and getting a few more build errors similar to the= se > ones. Are these two files only build error you get? >=20 >=20 > [1] > gcc (GCC) 8.0.1 20180401 (experimental) >=20 This fixes the easy ones. The harder one is in cuckoo hash. CC rte_table_hash_cuckoo.o lib/librte_table/rte_table_hash_cuckoo.c: In function =E2=80=98rte_table_ha= sh_cuckoo_create=E2=80=99: lib/librte_table/rte_table_hash_cuckoo.c:110:16: error: cast between incomp= atible function types from =E2=80=98rte_table_hash_op_hash=E2=80=99 {aka = =E2=80=98long unsigned int (*)(void *, void *, unsigned int, long unsigned= int)=E2=80=99} to =E2=80=98uint32_t (*)(const void *, uint32_t, uint32_t)= =E2=80=99 {aka =E2=80=98unsigned int (*)(const void *, unsigned int, unsig= ned int)=E2=80=99} [-Werror=3Dcast-function-type] .hash_func =3D (rte_hash_function)(p->f_hash), ^ cc1: all warnings being treated as errors Not sure what the right way to fix this one is. Hash table should not be de= fining its own special hash function prototype. Changing to a common definition is non-trivial and breaks ABI. Casting seems wrong, error prone, and a bad precedent in this case.