[XEN PATCH 0/3] Drop alternative definitions for unsupported GCCs

[XEN PATCH 0/3] Drop alternative definitions for unsupported GCCs

[nicola.vetrini]

From: Nicola Vetrini <nicola.vetrini@gmail.com>

Similar to e4a042062787, drop alternative defines for older GCC versions

Nicola Vetrini (3):
  xen/compiler: drop alternative unreachable() definition for older GCC
  xen/macros: Drop alternative definition of BUILD_BUG_ON(_ZERO)? for
    old GCC
  xen/efi: efibind: Drop alternative define for old GCC versions

 xen/arch/x86/include/asm/x86_64/efibind.h | 4 +---
 xen/include/xen/compiler.h                | 4 ----
 xen/include/xen/macros.h                  | 8 --------
 3 files changed, 1 insertion(+), 15 deletions(-)

-- 
2.43.0

[XEN PATCH 1/3] xen/compiler: drop alternative unreachable() definition for older GCC

[nicola.vetrini]

From: Nicola Vetrini <nicola.vetrini@gmail.com>

The GCC baseline version is 5.1, which supports __builtin_unreachable(),
therefore the alternative definition can be dropped

Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
---
Mentioned in https://gitlab.com/xen-project/xen/-/issues/201
---
 xen/include/xen/compiler.h | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 735c844d2d15..88bf26bc5109 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -47,11 +47,7 @@
 # define cf_check
 #endif
 
-#if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
-#define unreachable() do {} while (1)
-#else
 #define unreachable() __builtin_unreachable()
-#endif
 
 /*
  * Compilers estimate the size of an asm() block for inlining purposes.
-- 
2.43.0

Re: [XEN PATCH 1/3] xen/compiler: drop alternative unreachable() definition for older GCC

[Andrew Cooper]

On 13/08/2025 8:12 pm, nicola.vetrini@gmail.com wrote:
> From: Nicola Vetrini <nicola.vetrini@gmail.com>
>
> The GCC baseline version is 5.1, which supports __builtin_unreachable(),
> therefore the alternative definition can be dropped
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
> ---
> Mentioned in https://gitlab.com/xen-project/xen/-/issues/201

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

[XEN PATCH 2/3] xen/macros: Drop alternative definition of BUILD_BUG_ON(_ZERO)? for old GCC

[nicola.vetrini]

From: Nicola Vetrini <nicola.vetrini@gmail.com>

The toolchain baseline for GCC is 5.1, which supports _Static_assert
in c99 mode

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
---
Mentioned in https://gitlab.com/xen-project/xen/-/issues/201
---
 xen/include/xen/macros.h | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
index cd528fbdb127..f9ccde86fb23 100644
--- a/xen/include/xen/macros.h
+++ b/xen/include/xen/macros.h
@@ -40,9 +40,6 @@
 
 #ifndef __ASSEMBLY__
 
-/* All clang versions supported by Xen have _Static_assert. */
-#if defined(__clang__) || \
-    (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6))
 /* Force a compilation error if condition is true */
 #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
 
@@ -54,11 +51,6 @@
  */
 #define BUILD_BUG_ON_ZERO(cond) \
     (sizeof(struct { char c; _Static_assert(!(cond), "!(" #cond ")"); }) & 0)
-#else
-#define BUILD_BUG_ON_ZERO(cond) \
-    (sizeof(struct { unsigned u : !(cond); }) & 0)
-#define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond))
-#endif
 
 /*
  * Force a compilation error.  This is for code which, in the normal case,
-- 
2.43.0

Re: [XEN PATCH 2/3] xen/macros: Drop alternative definition of BUILD_BUG_ON(_ZERO)? for old GCC

[Andrew Cooper]

On 13/08/2025 8:12 pm, nicola.vetrini@gmail.com wrote:
> From: Nicola Vetrini <nicola.vetrini@gmail.com>
>
> The toolchain baseline for GCC is 5.1, which supports _Static_assert
> in c99 mode
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
> ---
> Mentioned in https://gitlab.com/xen-project/xen/-/issues/201

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Re: [XEN PATCH 2/3] xen/macros: Drop alternative definition of BUILD_BUG_ON(_ZERO)? for old GCC

[Jan Beulich]

On 13.08.2025 21:12, nicola.vetrini@gmail.com wrote:
> From: Nicola Vetrini <nicola.vetrini@gmail.com>
> 
> The toolchain baseline for GCC is 5.1, which supports _Static_assert
> in c99 mode

Hmm, interesting. I can confirm the behavior, but isn't this a bug? There's no
_Static_assert() in plain C99. Respective notes in the "Changes, New Features,
and Fixes" are also saying otherwise: https://gcc.gnu.org/gcc-4.6/changes.html
has "This support may be selected with -std=c1x, or -std=gnu1x for C1X with
GNU extensions." Nothing new is said in any of the respective documents up to
the release of gcc5. (In fact, the compiler accepts the construct even with
-std=c89.)

Our misra/C-language-toolchain.rst refers to a section in gcc12's doc which
doesn't mention _Static_assert() at all, afaics.

Jan

Re: [XEN PATCH 2/3] xen/macros: Drop alternative definition of BUILD_BUG_ON(_ZERO)? for old GCC

[Nicola Vetrini]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

On Thu, Aug 14, 2025, 10:08 Jan Beulich <jbeulich@suse.com> wrote:

> On 13.08.2025 21:12, nicola.vetrini@gmail.com wrote:
> > From: Nicola Vetrini <nicola.vetrini@gmail.com>
> >
> > The toolchain baseline for GCC is 5.1, which supports _Static_assert
> > in c99 mode
>
> Hmm, interesting. I can confirm the behavior, but isn't this a bug?
> There's no
> _Static_assert() in plain C99. Respective notes in the "Changes, New
> Features,
> and Fixes" are also saying otherwise:
> https://gcc.gnu.org/gcc-4.6/changes.html
> has "This support may be selected with -std=c1x, or -std=gnu1x for C1X with
> GNU extensions." Nothing new is said in any of the respective documents up
> to
> the release of gcc5. (In fact, the compiler accepts the construct even with
> -std=c89.)
>

 Some features that are part of the C99 standard are accepted as extensions
in C90 mode, and some features that are part of the C11 standard are
accepted as extensions in C90 and C99 modes. Use of the -std options listed
above disables these extensions where they conflict with the C standard
version selected

If my reading is correct then this paragraph gives them the leeway needed
to use it even in c89, except maybe with -pedantic


> Our misra/C-language-toolchain.rst refers to a section in gcc12's doc which
> doesn't mention _Static_assert() at all, afaics.
>
> Jan
>

I can check with my colleagues, but I suspect this is not documented as an
extension by GCC because it's not one in C11, and gcc12 supports all(?) of
C11, therefore it is an extension only with respect to certain conditions,
which GCC does not use as a category in their docs, but we keep track of
what is an extension and what is not, given the CU standard selected.

>

[-- Attachment #2: Type: text/html, Size: 2925 bytes --]

[XEN PATCH 3/3] xen/efi: efibind: Drop alternative define for old GCC versions

[nicola.vetrini]

From: Nicola Vetrini <nicola.vetrini@gmail.com>

Since the toolchain baseline for GCC is 5.1, there is no need for
this case.

Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
---
Mentioned in https://gitlab.com/xen-project/xen/-/issues/201
---
 xen/arch/x86/include/asm/x86_64/efibind.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/include/asm/x86_64/efibind.h b/xen/arch/x86/include/asm/x86_64/efibind.h
index b29342c61cac..d71b9324a6bb 100644
--- a/xen/arch/x86/include/asm/x86_64/efibind.h
+++ b/xen/arch/x86/include/asm/x86_64/efibind.h
@@ -173,10 +173,8 @@ typedef uint64_t   UINTN;
 #ifndef EFIAPI                  // Forces EFI calling conventions reguardless of compiler options
     #ifdef _MSC_EXTENSIONS
         #define EFIAPI __cdecl  // Force C calling convention for Microsoft C compiler
-    #elif __clang__ || __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4)
-        #define EFIAPI __attribute__((__ms_abi__))  // Force Microsoft ABI
     #else
-        #define EFIAPI          // Substitute expression to force C calling convention
+        #define EFIAPI __attribute__((__ms_abi__))  // Force Microsoft ABI
     #endif
 #endif
 
-- 
2.43.0

Re: [XEN PATCH 3/3] xen/efi: efibind: Drop alternative define for old GCC versions

[Andrew Cooper]

On 13/08/2025 8:12 pm, nicola.vetrini@gmail.com wrote:
> From: Nicola Vetrini <nicola.vetrini@gmail.com>
>
> Since the toolchain baseline for GCC is 5.1, there is no need for
> this case.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
> ---
> Mentioned in https://gitlab.com/xen-project/xen/-/issues/201

I personally am in favour of this change, but in the past there has been
objection to changing this header it is vendered from elsewhere.

e.g. far more could be stripped out if ...

> ---
>  xen/arch/x86/include/asm/x86_64/efibind.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/include/asm/x86_64/efibind.h b/xen/arch/x86/include/asm/x86_64/efibind.h
> index b29342c61cac..d71b9324a6bb 100644
> --- a/xen/arch/x86/include/asm/x86_64/efibind.h
> +++ b/xen/arch/x86/include/asm/x86_64/efibind.h
> @@ -173,10 +173,8 @@ typedef uint64_t   UINTN;
>  #ifndef EFIAPI                  // Forces EFI calling conventions reguardless of compiler options
>      #ifdef _MSC_EXTENSIONS
>          #define EFIAPI __cdecl  // Force C calling convention for Microsoft C compiler

... it's noted that Xen doesn't use MSC and I can't see anyone taking
the time to make it work.

~Andrew

Re: [XEN PATCH 3/3] xen/efi: efibind: Drop alternative define for old GCC versions

[Jan Beulich]

On 14.08.2025 00:39, Andrew Cooper wrote:
> On 13/08/2025 8:12 pm, nicola.vetrini@gmail.com wrote:
>> From: Nicola Vetrini <nicola.vetrini@gmail.com>
>>
>> Since the toolchain baseline for GCC is 5.1, there is no need for
>> this case.
>>
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@gmail.com>
>> ---
>> Mentioned in https://gitlab.com/xen-project/xen/-/issues/201
> 
> I personally am in favour of this change, but in the past there has been
> objection to changing this header it is vendered from elsewhere.

The two lines Nicola is taking out altogether were our additions already
anyway. Playing with them ought to be fine. Context may better be left
intact. I'd like to note though that in gnuefi the detection logic has
changed, too. Maintainers may want to sync that.

As to me, earlier on, objecting to fiddling with imported files here:
Now that maintainership has changed, the new maintainers will need to
make up their take on this.

Jan