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 1D5C4A0352 for ; Fri, 17 Dec 2021 10:51:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 171C140040; Fri, 17 Dec 2021 10:51:31 +0100 (CET) Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by mails.dpdk.org (Postfix) with ESMTP id 391EB40040 for ; Fri, 17 Dec 2021 10:51:30 +0100 (CET) Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 06B8440265 for ; Fri, 17 Dec 2021 09:51:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1639734690; bh=LcATklK5Oo34Vf77pcnj0pu6RblcUgAMEL2y24e0zQQ=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=TeusgQN5N4zGicFK3mGdZdaNcunKsn+ll2T7Zy9NPSXIBLVGGBkgHvX5z0r2VZprJ wd+v2b/Rp4GfjAK91xEH/CwMl3IIVr4EyX3FRvllnorEoKv7RU8qIUj8Pa0KYeH6xh HMgMiOk8zWiU7e3sgoN0VPrMkkvqgvfwYqOW0YbRBeccePe3xrlu9Y5lEYJ+HxAPgR y+67mT+XcUpfKvQMncdk+dkq9y311ZLhxxhpP2TlTxD5d4HIbo3sWY/g0+yp+iCyaZ U2qbG2RHj2U2/N8UUp8NErvKwBeC9vI4psa+s/JcQlt/x1ipJCCakBvlfPVvSel3G9 PO++o9Y+X0Ehg== Received: by mail-wm1-f71.google.com with SMTP id i15-20020a05600c354f00b0034566ac865bso779754wmq.6 for ; Fri, 17 Dec 2021 01:51:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=LcATklK5Oo34Vf77pcnj0pu6RblcUgAMEL2y24e0zQQ=; b=D9PiKOYxbpZL5S/qRsYTrkg5vsoBSIHgdpzBO059Yz2L9ACBSpRhfNWPAUXs0FEVPA VMI/A2Ah3OuzKymnKbgd0l0OI2H1mVeX1OtZrjY2zaPktbSWT/NVkHN78WLWrHD3YTCr dHHzVfmKH3S1rAQT4LVNnxcnESqhZzYcXRuWATbvoFdUVSk1uiUJPNEckPCSTOhSaNvN qkOUgyNCEcFswFDPLJjNnb5xWsmqpg9JKbEL9YnCcfXdiPQOf5Xut/7cgMprSYS13y92 k4EX25JmYzKs5MTY3N+MdHZfJP6MOvYmaje5U663jJcaOfORJA+oE6FcEFu+LrL+gtsP lzHg== X-Gm-Message-State: AOAM532SiN3hovmUi+cRw6RCcXR5T3l7t35W28bZimwD7ds7bY5UEuG0 V4RmtPC5nSVUWMrqhPWGZOyA/uRRUNJ43OpCf/WiZw7qLy869uQb61Cai2kMlJl+3npJD4jtCRA huWZrBN1N4lqa6f847/GhEBzI X-Received: by 2002:a1c:9acf:: with SMTP id c198mr7840838wme.117.1639734689091; Fri, 17 Dec 2021 01:51:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJzo/1XMK+sukHOxccBa7hRvj7a02wzylDwljg8Tn0NF5FHrALISQMlkgJ3E73GSjFmAutEm3g== X-Received: by 2002:a1c:9acf:: with SMTP id c198mr7840828wme.117.1639734688885; Fri, 17 Dec 2021 01:51:28 -0800 (PST) Received: from localhost.localdomain ([2001:67c:1560:8007::aac:c4ad]) by smtp.gmail.com with ESMTPSA id u14sm7297543wrf.39.2021.12.17.01.51.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Dec 2021 01:51:28 -0800 (PST) From: christian.ehrhardt@canonical.com To: stable@dpdk.org Cc: bruce.richardson@intel.com, ktraynor@redhat.com, Thomas Monjalon , Luca Boccassi , Ferruh Yigit , Christian Ehrhardt Subject: [PATCH] cryptodev: fix stringop-overflow build failure with gcc 10 Date: Fri, 17 Dec 2021 10:51:24 +0100 Message-Id: <20211217095124.3500864-1-christian.ehrhardt@canonical.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org From: Christian Ehrhardt 19.11 LTS releases started to fail to build in some newer releases due to newer gcc-10 compilers available. Those are mostly false positives [1][2] and to some extend covered by the already present backports of "4990929c60 eal/ppc: ignore GCC 10 stringop-overflow warnings" and "df17bcb43b eal/x86: ignore gcc 10 stringop-overflow warnings". But the combination of 19.11 and gcc 10.3.0 and LTO this can still exposes the issue. [ 549s] In function ‘_mm_storeu_si128’, [ 549s] inlined from ‘rte_memcpy_generic’ at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:508:2, [ 549s] inlined from ‘rte_cryptodev_sym_session_set_user_data’ at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:882:10: [ 549s] /usr/lib/gcc/x86_64-linux-gnu/10/include/emmintrin.h:727:8: error: writing 16 bytes into a region of size 0 [-Werror=stringop-overflow=] [ 549s] 727 | *__P = __B; [ 549s] | ^ [ 549s] ../lib/librte_cryptodev/rte_cryptodev.c: In function ‘rte_cryptodev_sym_session_set_user_data’: [ 549s] ../lib/librte_cryptodev/rte_cryptodev.h:984:4: note: at offset 0 to object ‘sess_data’ with size 0 declared here [ 549s] 984 | } sess_data[0]; [ 549s] | ^ The problem is that in this combination only at link time (LTO) the compiler will (false-)detect the problematic size of the target structure and break. To make things worse [3] fixed this problem for the same issue at actual build time, but the pragma has no effect at link time nor are any werror settings passed to the linker. For affected compilers set -Wno-stringop-overflow globally for the linker stage to avoid this breaking the build in any place. Buzilla ID: 908 [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955 [3]: https://github.com/DPDK/dpdk/commit/b5b3ea803e47 Signed-off-by: Christian Ehrhardt --- config/meson.build | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/config/meson.build b/config/meson.build index 4007b8f37c..25dec320ba 100644 --- a/config/meson.build +++ b/config/meson.build @@ -143,6 +143,14 @@ if numa_dep.found() and cc.has_header('numaif.h') dpdk_extra_ldflags += '-lnuma' endif +# Some false positives can trigger at LTO stage, so this warning needs to be +# disabled on the linker as well for gcc 10. +# Fixed in gcc-11 and not present =10.0') and cc.version().version_compare('<11.0') + add_project_link_arguments('-Wno-stringop-overflow', language: 'c') +endif + has_libfdt = 0 fdt_dep = cc.find_library('libfdt', required: false) if fdt_dep.found() and cc.has_header('fdt.h') -- 2.34.1