Dear Thomas, ----- Am 21. Jun 2026 um 9:06 schrieb Thomas Schwinge [email protected]:
> Hi GCC/RTEMS maintainers! > > On 2026-05-07T13:16:59+0200, I wrote: >> [...] >> >> The idea of transitioning libgomp from C to C++ implementation has come >> up a number of times, [...] >> >> I'm now working on this. >> >> For a start, I've assessed that all GCC configurations that support >> libgomp also are able to build the GCC/C++ front end, as far as I can >> easily tell. >> >> I'll try to be mindful about handling all of libgomp's implementation >> files, but may reach out to individual GCC target maintainers for >> 'libgomp/config/' files, for example, that I can't easily test myself. >> >> [...] > > Per my understanding, for GCC/RTEMS, libgomp is not enabled by default in > GCC 'configure.ac' (needs explicit '--enable-libgomp'), but it appears to > be supported: RTEMS is mentioned in 'libgomp/configure.ac', > 'libgomp/configure.tgt', and has 'libgomp/config/rtems/' files. Please > let me know in case libgomp/RTEMS is in fact not supported (anymore). > > Assuming it is supported, I shall try to not break it. it is enabled for all RTEMS targets supporting SMP. This is aarch64, arm, riscv, powerpc, and sparc. It is actively used and there is an ongoing activity sponsored by the European Space Agency to enable the usage in critical systems. Moving from C to C++ will cause them some headaches, however, this should be of no concern for the GCC development. > > During ongoing development, I'll need to run a number of GCC/libgomp > builds for RTEMS over the next few weeks/months (tentatively); therefore > would like to do it myself instead of asking you each time. > > I need GCC 'configure'd with '--enable-languages=c,c++,fortran', > '--enable-libgomp', and then 'make', and 'make check-target-libgomp' if > feasible. > > Ideally, easiest, I'd do native builds, but that may not be applicable > for RTEMS? I don't see any RTEMS systems listed on > <https://portal.cfarm.net/machines/list/>. Otherwise, cross builds with > testing option, or without testing, in case that's not feasible. (I > assume that, as for other configurations, also for RTEMS my C -> C++ > baseline conversion changes are good to go, once they compile without > error.) > > Per 'libgomp/configure.ac': > > *-*-rtems*) > AC_CHECK_TYPES([struct _Mutex_Control],[],[],[#include <sys/lock.h>]) > > ..., and 'libgomp/configure.tgt': > > *-*-rtems*) > # Use self-contained synchronization objects if provided by Newlib > if test "x$ac_cv_type_struct__Mutex_Control" = xyes ; then > config_path="rtems posix" > > ..., there appear to be two major configuration variants: either only > 'libgomp/config/posix/', or 'libgomp/config/rtems/' plus the former. (As > far as I can easily tell, there aren't any compile-time conditionals in > the 'libgomp/config/rtems/' files, so I assume I don't really care about > the specific CPU architecture.) This "if test "x$ac_cv_type_struct__Mutex_Control" = xyes ; then" is obsolete. The check is always true. I will remove this check. You have to compile RTEMS with a cross-compiler. I can send you some build scripts to build the tools, RTEMS, a simulator, and an OpenMP test program. Kind regards, Sebastian -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: [email protected] phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
