On Thu, May 7, 2026 at 7:18 AM Thomas Schwinge <[email protected]> wrote: > > 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), 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
This sounds like a good opportunity to improve -Wc++-compat; if you come across any incompatibilities in the transition that aren't also flagged by -Wc++-compat, be sure to report bugs for those.
