Re: Xen reliance on non-standard GCC features

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan