[PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc
Konstantin Ananyev
konstantin.v.ananyev at yandex.ru
Tue Apr 18 00:10:25 CEST 2023
17/04/2023 16:46, Tyler Retzlaff пишет:
> On Sun, Apr 16, 2023 at 10:29:38PM +0100, Konstantin Ananyev wrote:
>> 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 <roretzla at linux.microsoft.com>
>>>>> ---
>>>>> 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?
>
> i investigated and expirmented with this further. i can see now there
> were two things that were tripping things up portability wise.
>
> * it's still a forward declaration even if the full enum definition is
> visible and thus generates a warning (but not an error).
>
> * the use of __extension__ which is valid in this context because it is
> after all an extension (causes compilation error for msvc).
>
> my testing shows i'm still getting correct sizes (because the definition
> is visible) so what i'll do is update this patch to remove the use of
> __extension__ and allow the warning to be emitted for now. i think this
> is probably what you're preference would be.
>
> in a future series i will either suppress the warning for msvc or remove
> the declaration entirely which as you point out should not be needed due
> to the include via arch/rte_cpuflags.h -> include generic/rte_cpuflags.h.
Agree, let's try to remove this declaration.
I don't see any point to have declaration straight after defintion.
Thanks
Konstantin
>
> thanks!
>
>> 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
More information about the dev
mailing list