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 BFA2A438E5; Tue, 16 Jan 2024 23:18:24 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4856040278; Tue, 16 Jan 2024 23:18:24 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id C9502400D6 for ; Tue, 16 Jan 2024 23:18:22 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 9E650205F3; Tue, 16 Jan 2024 23:18:22 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: static_assert, sfc, and clang issues X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 16 Jan 2024 23:18:20 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F16A@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F169@smartserver.smartshare.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: static_assert, sfc, and clang issues Thread-Index: AdpIxg0jVf2qijggRy6UJVVTj0Ov3AAAdo8QAABwg/A= References: <20240116090301.4c29d5b7@hermes.local> <20240116215034.GA351@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35E9F169@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , "Stephen Hemminger" Cc: "Andrew Rybchenko" , X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Morten Br=F8rup [mailto:mb@smartsharesystems.com] > Sent: Tuesday, 16 January 2024 23.15 >=20 > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Tuesday, 16 January 2024 22.51 > > > > On Tue, Jan 16, 2024 at 09:03:01AM -0800, Stephen Hemminger wrote: > > > Ran into a corner case issue, so sending to mailing list for wider > > discussion. > > > > > > One improvement to DPDK code base planned is getting rid of > variable > > length arrays. > > > VLA's can cause bugs and are not supported by the Windows = compiler. > > > Gcc and Clang have a flag to warn on use of VLA's (-Wvla). > > > > > > In DPDK one use of VLA's is in the RTE_BUILD_BUG_ON macro. > > > The best path is to replace the undefined array access with a > better > > > static_assert() which is builtin to compilers. > > > > > > Using static_assert() is relatively easy, there are a few places > > where > > > it does detect use of non-constant expressions in existing code = but > > these > > > are fixable. > > > > > > But there is one case where use static_assert() runs into a Clang > bug > > > which is not fixed in distros: > > > > > > https://github.com/llvm/llvm-project/issues/55821 > > > > > > The code in question is in the sfc driver which for better or = worse > > > has lots of assertions. The problem is that clang (except in > > unreleased trunk) > > > can not handle static_assert in a switch leg. > > > > > > switch (actions->type) { > > > case RTE_FLOW_ACTION_TYPE_VOID: > > > SFC_BUILD_SET_OVERFLOW(RTE_FLOW_ACTION_TYPE_VOID, > > > actions_set); > > > break; > > > > > > ../drivers/net/sfc/sfc_flow.c:1635:4: error: expected expression > > > > > SFC_BUILD_SET_OVERFLOW(RTE_FLOW_ACTION_TYPE_VOID, > > > ^ > > > ../drivers/net/sfc/sfc_flow.h:36:2: note: expanded from macro > > 'SFC_BUILD_SET_OVERFLOW' > > > RTE_BUILD_BUG_ON((_action) >=3D sizeof(_set) * CHAR_BIT) > > > ^ > > > > > > > > > There are some workarounds: > > > 0. Ignore it, works on Gcc, and Clang fix is pending. > > > 1. Remove many of these RTE_BUILD_BUG_ON's. They are really not > > that helpful. > > > 2. Add additional { } to these switch cases so they become basic > > blocks > > > which works around the bug. > > > 3. Move the assertions out of the switch > > > > > > My preference is #2 but open to other options. > > > > +1 for #2 just make it a block. >=20 > I prefer that you implement the workaround in the RTE_BUILD_BUG_ON() > macro, by surrounding it by "do { } while (0)", like this: >=20 > #define RTE_BUILD_BUG_ON(condition) do { static_assert(!(condition), > #condition); } while (0) >=20 > And please mention the workaround reason, with the reference to the > clang bug, in the source code comment describing the function. Typo: "describing the function" -> "describing the RTE_BUILD_BUG_ON = macro" >=20 > The godbolt link in the clang issue seems happy with this workaround.