This topic is for testing 7/main with GCC 15.This includes removing errors, warnings, and fixing issues in add-ons and applications. Help is needed.
EDIT: See updated post made on 13 August 2025.
Updating GCC and other tools tends to expose new warnings and errors. @opticron and I have been fixing warnings in rtems and the networking packages (libbsd, lwip, and net services). There are still some warnings/errors in RTEMS itself which I have asked specific people for help with. We would like to branch RTEMS 7 with GCC 15 before GCC 16 is released. Feedback is needed for RTEMS and networking on real hardware along with compiling user applications and their dependencies.
Many of the warnings for RTEMS 6 have been fixed on 7/main as reflected in the table below which is current status as of 3 Aug 2025.
| RTEMS 6 w/GCC 13 | RTEMS 7 w//GCC 13 | RTEMS 7 w/GCC 15 | |
|---|---|---|---|
| BSPs Total | 222 | 189 | 189 |
| BSPs w/Errors Building | 4 | 3 | 3 |
| BSPs w/o Warnings | 63 | 145 | 145 |
| BSPs w/ Warnings | 159 | 44 | 44 |
| Unique Warnings | 532 | 5 | 5 |
You can build a GCC 15 tool chain for RTEMS 7 by using next/rtems-ARCH instead of 7/rtems-ARCH with the RSB (e.g. sb-set-builder). You likely want to use a different installation prefix. This will give you ARCH-rtems7 tools with GCC 15 instead of GCC 13. Proceed to build everything else as you normally do.
This is the over-arching ticket about updating RTEMS 7/main to use GCC 15 by default:
- Update main to GCC 15 - Overall issue to switch 7 from GCC 13 to GCC 15. Note: Reports from building all BSPs for 6, 7, and next are attached to this issue.
The following specific issues have been filed and are still open:
- irq-record.c and irq-generic.c: Indexing past end of array warning on multiple BSPs - Impacts about half a dozen BSPs
- powerpc: Invalid register expression - Two “assembler messages” that are in every PowerPC BSP build
- m68k/COBRA5475 & m5484FireEngine: Compile errors related to use of _VBR - Build error with two m68k Coldfire BSPs
Help is appreciated to ensure that user applications and their dependencies are working. If you find warnings or errors, please report them.
Is there any suggested workflow on testing? How do you get the 15 tools? What happens if you find a problem, open an issue?
The workflow to build the tools, network stacks, and add-on libraries is exactly the same if you build tools with the RSB by hand (e.g. sb-set-builder). Just make sure the gcc 15 tools are first in your PATH or that prefix is in the tools argument. The only difference as I mentioned is that you want to build next/rtems-ARCH instead of 7/rtems-ARCH. The installed tools will have ARCH-rtems7 in the name. This is why installing to a different prefix is probably wise for most people.
Reporting issues is another problem. How about just put “(GCC 15)” in the subject? I do not see having a tag per gcc version until the end of time.
And please make sure that it was introduced by GCC 15. A lot of what I blamed on GCC 14/15 was because we ignored issues with GCC 13 and likely earlier.
1 Like
Overnight build sweep results for FreeBSD 14.3 rtems-bsp-builder rtems7
look like my artisan crafted by-hand results.
Results for the sweep before that had build issues from the move of third-party code to contrib/.
Current status as of 13 August 2025.
Updating GCC and other tools tends to expose new warnings and errors. @opticron and I have been fixing warnings in rtems and the networking packages (libbsd, lwip, and net services). As of this post, there are no warnings left for rtems main (e.g. 7) with GCC 13 or 15. Thanks to @sebhub for fixing a couple of odd warnings that had lingered.
There are still some errors in RTEMS itself which I have asked specific people for help with. We would like to branch RTEMS 7 with GCC 15 before GCC 16 is released. Feedback is needed for RTEMS and networking on real hardware along with compiling user applications and their dependencies.
There are no warnings 7/main as reflected in the table below which is current status as of 13 Aug 2025. If someone wants specific warnings fixed on RTEMS 6, the change will need to be backported.
| RTEMS 6 w/GCC 13 | RTEMS 7 w//GCC 13 | RTEMS 7 w/GCC 15 | |
|---|---|---|---|
| BSPs Total | 222 | 190 | 190 |
| BSPs w/Errors Building | 4 | 3 | 3 |
| BSPs w/o Warnings | 63 | 190 | 190 |
| BSPs w/ Warnings | 159 | 0 | 0 |
| Unique Warnings | 532 | 0 | 0 |
Now that 7/main has no warnings, we can discuss enabling -Werror by default. This should help prevent new warnings being introduced by code changes.
You can build a GCC 15 tool chain for RTEMS 7 by using next/rtems-ARCH instead of 7/rtems-ARCH with the RSB (e.g. sb-set-builder). You likely want to use a different installation prefix. This will give you ARCH-rtems7 tools with GCC 15 instead of GCC 13. Proceed to build everything else as you normally do.
This is the over-arching ticket about updating RTEMS 7/main to use GCC 15 by default:
- Update main to GCC 15 - Overall issue to switch 7 from GCC 13 to GCC 15. **Note: Reports from building all BSPs for 6, 7, and next are attached to this issue. **
This is the only outstanding issue and it is a build error for multiple BSPs:
- m68k/COBRA5475 & m5484FireEngine: Compile errors related to use of _VBR - Build error with two m68k Coldfire BSPs
Help is appreciated to ensure that user applications and their dependencies are working. If you find warnings or errors, please report them.
Just following up that this effort has been successful. Building with GCC 15 is now warning free and testing has not turned up any issues. A manual “cron” build sweep has been run and the GCC 15 “next tools” run needs to be added to the OAR build farm. But all looks good.