Re: Xen reliance on non-standard GCC features

[Michal Orzel <michal.orzel@xxxxxxx>]

On 09/06/2023 11:47, Jan Beulich wrote:
> 
> 
> On 09.06.2023 11:36, Michal Orzel wrote:
>> On 09/06/2023 10:54, Jan Beulich wrote:
>>> On 08.06.2023 14:18, Roberto Bagnara wrote:
>>>> On 07/06/23 09:39, Jan Beulich wrote:
>>>>> On 05.06.2023 15:26, Roberto Bagnara wrote:
>>>>>> On 05/06/23 11:28, Jan Beulich wrote:
>>>>>>> On 05.06.2023 07:28, Roberto Bagnara wrote:
>>>>>>>> U6) Empty declarations.
>>>>>>
>>>>>> Examples:
>>>>>>
>>>>>> xen/arch/arm/arm64/lib/find_next_bit.c:57.29:
>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 
>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is 
>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>
>>>>>> xen/arch/arm/arm64/lib/find_next_bit.c:103.34:
>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 
>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is 
>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>
>>>>> Looks like these could be taken care of by finally purging our
>>>>> EXPORT_SYMBOL() stub.
>>>>>
>>>>>> xen/arch/arm/include/asm/vreg.h:143.26:
>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 
>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is 
>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>
>>>>>> xen/arch/arm/include/asm/vreg.h:144.26:
>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 
>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is 
>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>
>>>>> I'm having trouble spotting anything suspicious there.
>>>>
>>>> The macro expands to definitions of inline functions
>>>> and after the macro invocation there is a ";".
>>>>
>>>> The preprocessed code is then:
>>>>
>>>> static inline void foo() { ... }
>>>> ;
>>>>
>>>> where the final ";" is an empty declaration not allowed by
>>>> the C99 language standard.
>>>
>>> Oh, I see.
>>>
>>>> Removing the ";" after the macro invocation is a possible solution,
>>>> but other possibilities exist if this is strongly unwanted.
>>>
>>> We have other macros to instantiate functions, and there no stray
>>> semicolons are used. I think this wants doing the same way here, but it
>>> being Arm code the ultimate say is with the Arm maintainers.
>> Apart from vreg.h the same applies to TLB_HELPER of arm32/arm64.
>> I think also TYPE_SAFE would want to be fixed.
> 
> Indeed. For this last one I wonder though whether it wouldn't be better
> to continue to permit (really: require) the semicolon at the use sites,
> by putting the typedef-s last and omitting the semicolon in the macro
> definitions.
This would be an error I think since the functions are defined using this type
so it must be defined first. Unless there is a way to forward typedef. All in 
all,
removing semicolon at use sites is simpler.

~Michal