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 4E72EA04A2 for ; Fri, 17 Dec 2021 13:00:33 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1FF4D40143; Fri, 17 Dec 2021 13:00:33 +0100 (CET) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by mails.dpdk.org (Postfix) with ESMTP id 8B5B740040 for ; Fri, 17 Dec 2021 13:00:31 +0100 (CET) Received: by mail-ed1-f43.google.com with SMTP id y13so6762856edd.13 for ; Fri, 17 Dec 2021 04:00:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=ZU9F+2sxEwkR9BiFIljZduqNHvr7Sxz38tyJFWTx+Do=; b=SP1LBQHysA4nL/TzPAUlUKswu13ubxrJ9nXejMJfcm2/YEn0Kg7cBcRSuU444RV0+O V7BKz2ZPQExSW8oYb99AE2x4z+xh1QeuulFgO6f9YSoiINo2s2+KWqUWnIUEIVHQV2IA nedtbYkTvPhCCyZh/TvOKO6OksUUaM6BCQy7Lt63epjIzyRgpcvaGVEJP93Ss1cNOOlY s1th3Okg7p73MYcsmgsTW0a1fqAzCM/4ye9IlublkDgl4plv758mWDPLQ/zV9jo0ke+z GwRFMnbDNFUtA9ra7fOuU/SlRwDj8ImuGifzpSUghjFc9D7/gS+Hoti+RbAm2lklTjaH +CAQ== X-Gm-Message-State: AOAM533LReFGlkeYCHJdOjAvblw9M976kI1+85ybd4M5RuMEfJPfY9CK IikEmSGmOMm9ZGFHnck65PCRWr1S/A8= X-Google-Smtp-Source: ABdhPJwQKBkWq0ovD7xbu/8qq6oPZWSzv6SoCL831mDj+jkpckn4q9mp+tkXOqWumhxwufB5Xl+b+g== X-Received: by 2002:aa7:dd47:: with SMTP id o7mr2550347edw.34.1639742431239; Fri, 17 Dec 2021 04:00:31 -0800 (PST) Received: from localhost ([137.220.125.106]) by smtp.gmail.com with ESMTPSA id cw5sm2876425ejc.74.2021.12.17.04.00.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Dec 2021 04:00:30 -0800 (PST) Message-ID: <579800f9f68738b114417f807c3a539fd96a093b.camel@debian.org> Subject: Re: [PATCH] cryptodev: fix stringop-overflow build failure with gcc 10 From: Luca Boccassi To: christian.ehrhardt@canonical.com, stable@dpdk.org Cc: bruce.richardson@intel.com, ktraynor@redhat.com, Thomas Monjalon , Ferruh Yigit Date: Fri, 17 Dec 2021 12:00:30 +0000 In-Reply-To: <20211217095124.3500864-1-christian.ehrhardt@canonical.com> References: <20211217095124.3500864-1-christian.ehrhardt@canonical.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.38.3-1+plugin MIME-Version: 1.0 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 On Fri, 2021-12-17 at 10:51 +0100, christian.ehrhardt@canonical.com wrote: > From: Christian Ehrhardt >=20 > 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". >=20 > But the combination of 19.11 and gcc 10.3.0 and LTO this can still > exposes the issue. >=20 > [ 549s] In function =E2=80=98_mm_storeu_si128=E2=80=99, > [ 549s] inlined from =E2=80=98rte_memcpy_generic=E2=80=99 > =C2=A0=C2=A0at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:508= :2, > [ 549s] inlined from =E2=80=98rte_cryptodev_sym_session_set_user_dat= a=E2=80=99 > =C2=A0=C2=A0at ../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: > =C2=A0=C2=A0error: writing 16 bytes into a region of size 0 > =C2=A0=C2=A0[-Werror=3Dstringop-overflow=3D] > [ 549s] 727 | *__P =3D __B; > [ 549s] | ^ > [ 549s] ../lib/librte_cryptodev/rte_cryptodev.c: > =C2=A0=C2=A0In function =E2=80=98rte_cryptodev_sym_session_set_user_data= =E2=80=99: > [ 549s] ../lib/librte_cryptodev/rte_cryptodev.h:984:4: note: > =C2=A0=C2=A0at offset 0 to object =E2=80=98sess_data=E2=80=99 with size 0= declared here > [ 549s] 984 | } sess_data[0]; > [ 549s] | ^ >=20 > 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. >=20 > For affected compilers set -Wno-stringop-overflow globally for > the linker stage to avoid this breaking the build in any place. >=20 > Buzilla ID: 908 >=20 > [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94335 > [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92955 > [3]: https://github.com/DPDK/dpdk/commit/b5b3ea803e47 >=20 > Signed-off-by: Christian Ehrhardt > --- > =C2=A0config/meson.build | 8 ++++++++ > =C2=A01 file changed, 8 insertions(+) >=20 > 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') > =C2=A0 dpdk_extra_ldflags +=3D '-lnuma' > =C2=A0endif > =C2=A0 >=20 > +# Some false positives can trigger at LTO stage, so this warning needs t= o be > +# disabled on the linker as well for gcc 10. > +# Fixed in gcc-11 and not present +# https://bugs.dpdk.org/show_bug.cgi?id=3D908 > +if cc.get_id() =3D=3D 'gcc' and cc.version().version_compare('>=3D10.0')= and cc.version().version_compare('<11.0') > + add_project_link_arguments('-Wno-stringop-overflow', language: 'c') > +endif > + > =C2=A0has_libfdt =3D 0 > =C2=A0fdt_dep =3D cc.find_library('libfdt', required: false) > =C2=A0if fdt_dep.found() and cc.has_header('fdt.h') Sounds reasonable to me. Is it possible to detect that LTO is used, to further restrict when this is applied? --=20 Kind regards, Luca Boccassi