From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FaV2Gn+6ZSc3G44BgvAUzs8o8VVJ27mEUpuElufuNqg=; b=NSbFfD0Wqnu4CaCaxY4CKj6xsGTU4zVg0p3uEt9gHRVmc9UaHyKQgTzztjJtGv6U3N MOqul4icTecP7hSQ7qkfNfKJphsWI8W0Lf/oNFKDw/4N5maaBRP6y3afJsfjooCgPOQT z85bTrgRijtxHX942cJ974dA70wiy0bXvNgbsBgV33lLR6vAEtr2FHmagEQI3hPcBYpi 2qzBHkVfW4vR3n1/g+ELbjZFvSBf7goCZGiKXqBcdJbS9oDjO2F/imO9MtuXHK87awme hyfFfVLU5WeA3llWdvJKY1a+F4X0NghbyYto4NUJ4AJukl97faazK8VlvPYR59GRKV/l IIZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=FaV2Gn+6ZSc3G44BgvAUzs8o8VVJ27mEUpuElufuNqg=; b=c2igo4LusZo3WKNoU8D1xI7vDZ6IW8DzER5OvM1K8sYYQGMLrCFkI6/ss8YxjC63Rj BmSUSAKj2zsotr4C8SFKLOn1FaTO1W4Dpz03S3Yp6NA0TPPJtySa8bcehVHbNb12N1go 4zEzjuvaiIrlKnTTc0A9PFjmSimVP14W700hWw+HgMeyyG9PzVJ9FD93eXEMzoQVRvWz qbU8dB1y8RTvY/sZvSef/bPNFfpmM+wZseKKUOagIaMXczwxV7A3wr5qYMvsRtduGzUp 7llGHckl0it0T2lQUyeSPrh5ur309w9FQ2dDeGkkCvlTwOO8azCEE3W9H+LG34qMTOaF WScA== X-Gm-Message-State: AElRT7GAvpZ5NwmMSM5SMWbkXGMIzcuYb5EZirzv2tO0Eo+WhgNAy+2q 8XNMmn2hAcKgyzOh6Q1X6vPhbQ== X-Google-Smtp-Source: AIpwx49AyrPEA8IWcYUAGWTp48Dxdd5yYb6jt+4R+nL2F5Z1RpatT1L+RF9BM73Foahpqtw/Xqkdaw== X-Received: by 2002:a17:902:7784:: with SMTP id o4-v6mr8887065pll.163.1522768243800; Tue, 03 Apr 2018 08:10:43 -0700 (PDT) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id 13sm6477129pfm.10.2018.04.03.08.10.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Apr 2018 08:10:43 -0700 (PDT) Date: Tue, 3 Apr 2018 08:10:36 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: dev@dpdk.org Message-ID: <20180403081036.4061b248@xeon-e3> In-Reply-To: <8988b191-30cd-a9fe-1cd2-8625c671a7fe@intel.com> 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 Subject: Re: [dpdk-dev] [PATCH v3 0/2] gcc-8 build fixes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 15:10:44 -0000 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.