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
