Transitioning libgomp from C to C++ implementation

[Martin Uecker]

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