Re: Transitioning libgomp from C to C++ implementation

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.