GCC 4.1.2 is from 2007, and Binutils 2.16 is a similar vintage. Clang 3.5 is
from 2014. Supporting toolchains this old is a massive development and
testing burden.
Set a minimum baseline of GCC 5.1 across the board, along with Binutils 2.25
which is the same age. These were chosen *3 years ago* as Linux's minimum
requirements because even back then, they were ubiquitous in distros. Choose
Clang/LLVM 11 as a baseline for similar reasons; the Linux commit making this
change two years ago cites a laudry list of code generation bugs.
This will allow us to retire a lot of compatiblity logic, and start using new
features previously unavailable because of no viable compatibility option.
Merge the ARM 32bit and 64bit sections now they're the same.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
PPC doesn't have a minimum set stated yet, but CI tests GCC 10 from Debian 11.
This will require dropping some containers from CI. CentOS 7 notably.
In terms of specific new features, I'm interested in:
* __has_include() to remove the asm-generic makefile tangle
* asm goto (), to remove .fixup and code generation for error handling.
and these too, but will require MISRA adjustments:
* _Generic() to make properly const-preserving wrappers
* Updating our -std to gnu11, which drops further compatibility logic
When the arguments die down, I'll add a hunk to CHANGELOG.md as this is very
significant.
---
README | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/README b/README
index 9d9c6fc324c6..be90be3910d4 100644
--- a/README
+++ b/README
@@ -38,16 +38,13 @@ provided by your OS distributor:
* GNU Make v3.80 or later
* C compiler and linker:
- For x86:
- - GCC 4.1.2_20070115 or later
- - GNU Binutils 2.16.91.0.5 or later
+ - GCC 5.1 or later
+ - GNU Binutils 2.25 or later
or
- - Clang/LLVM 3.5 or later
- - For ARM 32-bit:
- - GCC 4.9 or later
- - GNU Binutils 2.24 or later
- - For ARM 64-bit:
+ - Clang/LLVM 11 or later
+ - For ARM:
- GCC 5.1 or later
- - GNU Binutils 2.24 or later
+ - GNU Binutils 2.25 or later
- For RISC-V 64-bit:
- GCC 12.2 or later
- GNU Binutils 2.39 or later
base-commit: ac29d63a0fa6a3ed98ecf86f95995811c301308f
--
2.39.5
On 2025-03-07 18:54, Andrew Cooper wrote: > GCC 4.1.2 is from 2007, and Binutils 2.16 is a similar vintage. Clang > 3.5 is > from 2014. Supporting toolchains this old is a massive development and > testing burden. > > Set a minimum baseline of GCC 5.1 across the board, along with Binutils > 2.25 > which is the same age. These were chosen *3 years ago* as Linux's > minimum > requirements because even back then, they were ubiquitous in distros. > Choose > Clang/LLVM 11 as a baseline for similar reasons; the Linux commit > making this > change two years ago cites a laudry list of code generation bugs. > > This will allow us to retire a lot of compatiblity logic, and start > using new > features previously unavailable because of no viable compatibility > option. > > Merge the ARM 32bit and 64bit sections now they're the same. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > --- > CC: Anthony PERARD <anthony.perard@vates.tech> > CC: Michal Orzel <michal.orzel@amd.com> > CC: Jan Beulich <jbeulich@suse.com> > CC: Julien Grall <julien@xen.org> > CC: Roger Pau Monné <roger.pau@citrix.com> > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com> > CC: Bertrand Marquis <bertrand.marquis@arm.com> > CC: Oleksii Kurochko <oleksii.kurochko@gmail.com> > CC: Shawn Anastasio <sanastasio@raptorengineering.com> > > PPC doesn't have a minimum set stated yet, but CI tests GCC 10 from > Debian 11. > > This will require dropping some containers from CI. CentOS 7 notably. > > In terms of specific new features, I'm interested in: > > * __has_include() to remove the asm-generic makefile tangle > * asm goto (), to remove .fixup and code generation for error > handling. > > and these too, but will require MISRA adjustments: > > * _Generic() to make properly const-preserving wrappers Perhaps stating something that is already well-known, but this effectively means moving from MISRA C:2012 Amendment 2 as a target to, at least, MISRA C:2012 Amendment 3, as that version contains rules in series 23 for _Generic. > * Updating our -std to gnu11, which drops further compatibility logic > > When the arguments die down, I'll add a hunk to CHANGELOG.md as this is > very > significant. > --- > README | 13 +++++-------- > 1 file changed, 5 insertions(+), 8 deletions(-) > > diff --git a/README b/README > index 9d9c6fc324c6..be90be3910d4 100644 > --- a/README > +++ b/README > @@ -38,16 +38,13 @@ provided by your OS distributor: > * GNU Make v3.80 or later > * C compiler and linker: > - For x86: > - - GCC 4.1.2_20070115 or later > - - GNU Binutils 2.16.91.0.5 or later > + - GCC 5.1 or later > + - GNU Binutils 2.25 or later > or > - - Clang/LLVM 3.5 or later > - - For ARM 32-bit: > - - GCC 4.9 or later > - - GNU Binutils 2.24 or later > - - For ARM 64-bit: > + - Clang/LLVM 11 or later > + - For ARM: > - GCC 5.1 or later > - - GNU Binutils 2.24 or later > + - GNU Binutils 2.25 or later > - For RISC-V 64-bit: > - GCC 12.2 or later > - GNU Binutils 2.39 or later > > base-commit: ac29d63a0fa6a3ed98ecf86f95995811c301308f -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
On 07/03/2025 6:22 pm, Nicola Vetrini wrote: > On 2025-03-07 18:54, Andrew Cooper wrote: >> and these too, but will require MISRA adjustments: >> >> * _Generic() to make properly const-preserving wrappers > > Perhaps stating something that is already well-known, but this > effectively means moving from MISRA C:2012 Amendment 2 as a target to, > at least, MISRA C:2012 Amendment 3, as that version contains rules in > series 23 for _Generic. Yes, I was expecting something along these lines. It's also why I don't suggest we start using it immediately. (There's *loads* of non-MISRA related work to do when these changes get accepted.) Part of the justification for doing the MISRA work upstream was so it could stay "clean" on an ongoing basis. The corollary to this is that our choice of MISRA standard needs to adapt as upstream Xen changes. Do you have any insight on how disruptive this would be? I presume it's not as simple as running sed over our docs and Eclair config, but I also don't imagine it's a giant task either. ~Andrew
On 2025-03-07 19:30, Andrew Cooper wrote: > On 07/03/2025 6:22 pm, Nicola Vetrini wrote: >> On 2025-03-07 18:54, Andrew Cooper wrote: >>> and these too, but will require MISRA adjustments: >>> >>> * _Generic() to make properly const-preserving wrappers >> >> Perhaps stating something that is already well-known, but this >> effectively means moving from MISRA C:2012 Amendment 2 as a target to, >> at least, MISRA C:2012 Amendment 3, as that version contains rules in >> series 23 for _Generic. > > Yes, I was expecting something along these lines. It's also why I > don't > suggest we start using it immediately. (There's *loads* of non-MISRA > related work to do when these changes get accepted.) > > > Part of the justification for doing the MISRA work upstream was so it > could stay "clean" on an ongoing basis. The corollary to this is that > our choice of MISRA standard needs to adapt as upstream Xen changes. > > > Do you have any insight on how disruptive this would be? I presume > it's > not as simple as running sed over our docs and Eclair config, but I > also > don't imagine it's a giant task either. > Yes, indeed. I needs a global re-evaluation due to new rules being introduced (e.g. _Noreturn handling gets its own rules in Amendment 3) so those would need to be discussed in-depth, but the impact is probably not dramatic overall in terms of configuration changes, as most of the rules are unchanged. > ~Andrew -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
Hi, On 07/03/2025 17:54, Andrew Cooper wrote: > GCC 4.1.2 is from 2007, and Binutils 2.16 is a similar vintage. Clang 3.5 is > from 2014. Supporting toolchains this old is a massive development and > testing burden. > > Set a minimum baseline of GCC 5.1 across the board, along with Binutils 2.25 > which is the same age. These were chosen *3 years ago* as Linux's minimum > requirements because even back then, they were ubiquitous in distros. Choose > Clang/LLVM 11 as a baseline for similar reasons; the Linux commit making this > change two years ago cites a laudry list of code generation bugs. > > This will allow us to retire a lot of compatiblity logic, and start using new > features previously unavailable because of no viable compatibility option. > > Merge the ARM 32bit and 64bit sections now they're the same. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <jgrall@amazon.com> Cheers, -- Julien Grall
© 2016 - 2025 Red Hat, Inc.