On 28/4/2022 6:04 pm, Sebastian Huber wrote: > On 28.04.22 09:52, Chris Johns wrote: >> On 27/4/2022 4:57 pm, Sebastian Huber wrote: >>> Hello, >>> >>> we have to select a GCC version for the RTEMS 6 release. Currently, GCC 10 >>> is >>> used, however, with the release of GCC 10.4 this year it will reach its end >>> of >>> life. Other options are GCC 11 and 12. GCC 12 will be released in the next >>> weeks. It has some nice features: >>> >>> * Initialization of stack variables: >>> >>> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init >>> >>> >>> >>> * Improved static analysis with -fanalyzer >>> >>> * Improved gcov support, with the ability to back port changes from GCC 13: >>> >>> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593536.html >>> >>> * Upstream maintenance for the next three years >>> >>> The draw back is that it is brand new. >>> >> What about rtems 6 shipping with 10 and then we move to 12 and test and if it >> looks good we release 7? >> >> The rational is my testing with rtems 6 + gcc 10 is good so we have a stable >> base to move from. Without this step we have no means for users to move back >> if >> there are issues. > > More releases means more maintenance overhead. Since GCC 12 is under active > upstream maintenance, compiler issues can be fixed by the GCC maintainers in > contrast to GCC 10.
Yes it does mean that could happen but it also means 6 and 7 are closer in terms of rtems.git etc so back ports here are simpler. Plus if rtems 6 is not working and 7 is the user can just move forward to 7. I suppose there is no prefect solution and we do not have a crystal ball so we will have to decide and hope we are OK. The positive aspect is 6 and 7 will both be waf based and that helps deployment solutions user have, eg EPICS. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel