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 012A5438E3; Tue, 16 Jan 2024 18:03:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 72C4340278; Tue, 16 Jan 2024 18:03:06 +0100 (CET) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by mails.dpdk.org (Postfix) with ESMTP id 9136C400D6 for ; Tue, 16 Jan 2024 18:03:05 +0100 (CET) Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1d3e416f303so36707025ad.0 for ; Tue, 16 Jan 2024 09:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1705424584; x=1706029384; darn=dpdk.org; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=pc5+UXMNFbrch/ZZIRvXTNIhlSfoDnWc6xifAGhzh94=; b=ZIV+gRUcbJCVDWqdFHUDzVYN29owM9qNzPIA2bnTMExZRRb5niCYvZBgla6aF6LKZb Cx2qRXBCD0LXSljLZOmb/yr+Om/spwKqFsjgmfD4XINH+Pu9xmN8XQA5EshgMFkZmbK4 M8t5Da4XhMm3j2OyajkRi47QUqBHHZrTzg8miZS2WDf5KWXI5YZ2KAv8T20dywoxdVnQ faUU3j2r9JrZrgaOuRyTBPba7upVkv9e1f01L713AG3tZ3bcW1CQCIW0gRb+oOUz4fGi pKBdwypqMmHqj+w/pdOEzcudZ9CHgmuIaQ+cWdrpxbjtzVZhb3reM1TM3UUrC0Gnh7J2 HgqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705424584; x=1706029384; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pc5+UXMNFbrch/ZZIRvXTNIhlSfoDnWc6xifAGhzh94=; b=GfNEhiVmOyuXZ9YDfycsvh//n20AMVSowsFvhUEaUbFGJxzd2iY2SumzFPaRtTO8CP lpAee3wd7f6ML6PTuGsaA843kM3rBK17dAnHghdibybzcKNnYzeBKUhSwKJepzRhLdFz YeED5NYp1FaJfv5DqoHCd4dGg6LBK2o252UwbcOwsK66iNWB5qAicofjIiFVj0H7RtMt 4htJQ0k37QGyaKimfNZlsJyRf6D0CUpao/w2kmqtghH4ql6Hz1bvLtHmXp+B9E8lSHjb 4uEh5E6/+9F01MiV6dcwYVUSOK0Ea6N7wugpMlVvMJt5BrxbVbrCQ9fnoGUQIlWABQPv YysA== X-Gm-Message-State: AOJu0YxO4ABP+XEfmCI410+54ysE5sh5zQHJ/x2CrD5m52mvRvTjXzKY 596v3RptKY85EoJNxu4qvyQqQYg1r4FymfaLc0JmS+u+m165lQ== X-Google-Smtp-Source: AGHT+IHWCANpA8r/Jqv6cJA+MkITtOuYvMIRf8UIPeehRpvTg08/YIf15GJXhcuIJT+DebaIcvVgcQ== X-Received: by 2002:a17:902:7ec2:b0:1d5:a9f9:ba9a with SMTP id p2-20020a1709027ec200b001d5a9f9ba9amr3756512plb.31.1705424584373; Tue, 16 Jan 2024 09:03:04 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id u14-20020a170902e80e00b001d4abc234a7sm9453662plg.100.2024.01.16.09.03.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jan 2024 09:03:04 -0800 (PST) Date: Tue, 16 Jan 2024 09:03:01 -0800 From: Stephen Hemminger To: Andrew Rybchenko Cc: dev@dpdk.org Subject: static_assert, sfc, and clang issues Message-ID: <20240116090301.4c29d5b7@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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) >= 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.