Am Donnerstag, dem 07.05.2026 um 13:16 +0200 schrieb Thomas Schwinge: > Hi! > > This is not intended to turn into a "color of the bike shed" discussion, > and also not into a "would additionally be nice to do [...]" discussion. > ;-) > > > The idea of transitioning libgomp from C to C++ implementation has come > up a number of times, where the clunkiness that comes with C++ is > believed to be favorable compared to the clunkiness of the C > implementation. > > This was, for example, in contexts such as generally enhancing type > safety, refactoring certain data structures (for various reasons), > potentially making light use of inheritance (for example, in libgomp > plugins),
I am not convinced that moving to C++ actually makes code more type safe or otherwise better. I am not working on libgomp, so my opinion may not be important. But for libraries such libubsan I observe that people created alternatives in C so having a C version would generally be more useful. Martin > and most recently in context of an upcoming OpenMP OMPT > implementation (see > <https://www.openmp.org/spec-html/5.0/openmpsu15.html> "OpenMP 5.0", > "OMPT" etc.), to be able to use "boolean templates" as a compilation > toggle, to get certain functions compiled for both of with vs. without > OMPT support, and dynamically at run time, if OMPT isn't actually > enabled, be able to branch to the "fast" variants that don't maintain all > the OMPT state (including less register usage). That appears to be much > better implementable with C++, compared to '__builtin_expect' or C > preprocessor tricks and duplicate compilation, for example. > > We agree to not introduce any libstdc++ dependency on libgomp, no RTTI, > no C++ exceptions. A while ago, Tobias already got Jakub to agree: > > > <jakub> I can live with g++ -fno-rtti -fno-exceptions without libstdc++ > > dependencies if really needed > > We also intend to do a performance evaluation using the > <https://github.com/EPCCed/epcc-openmp-microbenchmarks> > "EPCC OpenMP MicroBenchmark Suite", with the goal to demonstrate > negligible performance overhead introduced by the OMPT implementation > assuming no OMPT tool actually loaded. > > > 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. > > As much as possible, I'd like to implemented and upstream the necessary > changes already in the current C implementation (for example, make 'enum' > usage compatible for both C and C++), but that won't be possible for all > changes, obviously. I'll reach out in separate emails for any cases > where it's not obvious which way is best to address certain C vs. C++ > incompatibilities. > > > Grüße > Thomas
