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 6AE3342961; Sun, 16 Apr 2023 23:29:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4135140EDE; Sun, 16 Apr 2023 23:29:44 +0200 (CEST) Received: from forward500c.mail.yandex.net (forward500c.mail.yandex.net [178.154.239.208]) by mails.dpdk.org (Postfix) with ESMTP id 121E240C35 for ; Sun, 16 Apr 2023 23:29:43 +0200 (CEST) Received: from mail-nwsmtp-smtp-production-main-46.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-46.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:6294:0:640:3833:0]) by forward500c.mail.yandex.net (Yandex) with ESMTP id 7AEF05E4F0; Mon, 17 Apr 2023 00:29:42 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-46.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id cTiCsPnWtCg0-MUbBO8wP; Mon, 17 Apr 2023 00:29:41 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1681680581; bh=jUC5Nqgk3flp0aHnfin1JOhfVjgMNy+AWSxH+/5Tfms=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=v5iTPiXInHyzuL+FzEhshZm2HGdUrXYH1Ym11bygYYbXl7YFK6jgqeBCnKszsb3DZ eD9uq1k4odAhJB0i8I4QtnzpEuPzBfO/ZWRYBZXGiJvG7euItPKkwqb/bZFYPluC7T 0okyoxyto660G+yW7t0tLyqpOf6BG0lX9sNh1BEA= Authentication-Results: mail-nwsmtp-smtp-production-main-46.myt.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5713dbf3-25d0-37c2-5996-2e6344bcee18@yandex.ru> Date: Sun, 16 Apr 2023 22:29:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc To: Tyler Retzlaff Cc: dev@dpdk.org, bruce.richardson@intel.com, david.marchand@redhat.com, thomas@monjalon.net, mb@smartsharesystems.com, konstantin.ananyev@huawei.com References: <1680558751-17931-1-git-send-email-roretzla@linux.microsoft.com> <1680741919-22102-1-git-send-email-roretzla@linux.microsoft.com> <1680741919-22102-7-git-send-email-roretzla@linux.microsoft.com> <54a3d95b-51b3-6f3e-7d2f-d893ae9a8c4a@yandex.ru> <20230410205326.GA4798@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Content-Language: en-US From: Konstantin Ananyev In-Reply-To: <20230410205326.GA4798@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 10/04/2023 21:53, Tyler Retzlaff пишет: > On Mon, Apr 10, 2023 at 08:59:33PM +0100, Konstantin Ananyev wrote: >> 06/04/2023 01:45, Tyler Retzlaff пишет: >>> Forward declaration of a typedef is a non-standard extension and is not >>> supported by msvc. Use an int instead. >>> >>> Abstract the use of the int/enum rte_cpu_flag_t in function parameter >>> lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t >>> identifier. >>> >>> Remove the use of __extension__ on function prototypes where >>> rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the >>> conditionally compiled __extension__ at the non-standard forward >>> declaration site. >>> >>> Signed-off-by: Tyler Retzlaff >>> --- >>> lib/eal/include/generic/rte_cpuflags.h | 12 +++++++----- >>> 1 file changed, 7 insertions(+), 5 deletions(-) >>> >>> diff --git a/lib/eal/include/generic/rte_cpuflags.h b/lib/eal/include/generic/rte_cpuflags.h >>> index d35551e..87ab03c 100644 >>> --- a/lib/eal/include/generic/rte_cpuflags.h >>> +++ b/lib/eal/include/generic/rte_cpuflags.h >>> @@ -44,8 +44,12 @@ struct rte_cpu_intrinsics { >>> /** >>> * Enumeration of all CPU features supported >>> */ >>> +#ifndef RTE_TOOLCHAIN_MSVC >>> __extension__ >>> -enum rte_cpu_flag_t; >>> +typedef enum rte_cpu_flag_t rte_cpu_flag_t; >>> +#else >>> +typedef int rte_cpu_flag_t; >>> +#endif >> >> >> Just curious what exactly MSVC doesn't support here? >> Is that construction like: >> enum rte_cpu_flag_t {....}; >> enum rte_cpu_flag_t; >> ... >> Or something else? > > Forward declaration of an enum is non standard. It's probably only > allowed by gcc as an extension because gcc will make some kind of > implementation specific promise for it always to be `int` size by > default (assuming no other -foptions). I understood that part, what is not clear to me from where we are getting forward declarations? As I remember the usual organization of arch specific rte_cpuflags.h: /* type definition */ enum rte_cpu_flag_t {...}; /some other stuff */ #include "generic/rte_cpuflags.h" Which contains 'enum rte_cpu_flag_t' type declaration. But it doesn't look like a forward declaration to me. Is there a place where we do include "generic/rte_cpuflags.h" directly (not from arch specific header)? If so. might be we should change it to include arch specific header instead? > > If the enum was defined before reference it would probably be accepted > by msvc since it could 'see' the definition and know the integer width > in use. > >> >> >>> /** >>> * Get name of CPU flag >>> @@ -56,9 +60,8 @@ struct rte_cpu_intrinsics { >>> * flag name >>> * NULL if flag ID is invalid >>> */ >>> -__extension__ >>> const char * >>> -rte_cpu_get_flag_name(enum rte_cpu_flag_t feature); >>> +rte_cpu_get_flag_name(rte_cpu_flag_t feature); >>> /** >>> * Function for checking a CPU flag availability >>> @@ -70,9 +73,8 @@ struct rte_cpu_intrinsics { >>> * 0 if flag is not available >>> * -ENOENT if flag is invalid >>> */ >>> -__extension__ >>> int >>> -rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature); >>> +rte_cpu_get_flag_enabled(rte_cpu_flag_t feature); >>> /** >>> * This function checks that the currently used CPU supports the CPU features