Hi! Let me pick up one very specific discussion item here:
On 2026-05-07T16:45:49+0200, Tobias Burnus <[email protected]> wrote: > Richard Biener: >> Do you plan there to be changes of the ABI and thus GCCs middle-end >> interfacing? > > The idea is to use a lot of 'extern "C" {'. > > In particular, the ABI between compiler and libgomp shall remain the same; Right -- and sorry, belatedly, for not mentioning that "detail" in my initial email. It was just so obvious to me. ;-) So, during the course of the implementation, I've learned my fair share about where C++ diverges from C, that has an effect on the ABI. (Such as, for example, a "hidden" 'struct' return type propagating onto the function symbol itself.) I've fixed up things as I ran into them during my testing, but as we all know, testing is limited by the respective test cases, and I'm not convinced that I caught all issues -- in particular for libgomp symbols that exist only for ABI backwards compatibility. I'd like to properly compare the existing C vs. upcoming C++ libgomp ABI, in a structured way. We could rely on careful manual review of the changes (..., but...), plus a one-off/manual comparison with 'readelf' (or even libabigail maybe?), but what about this following idea: integrate into libgomp what libstdc++ already has as 'make check-abi', which is a "symbol-table regression test". We'll have a set of baseline tables (established from the current libgomp C builds), which any later libgomp-under-test gets checked against, as part of regular 'make check-target-libgomp', and any divergence results in FAILs, which then need to be addressed in the appropriate way. Baseline tables for libstdc++ are provided per target in 'libstdc++-v3/config/abi/post/[...]'. For libgomp maybe we'll be able to derive (most of?) that programmatically from 'libgomp/libgomp.map', given that the latter isn't using wildcards in the same way as libstdc++ does? (I've not yet fully thought that through.) In addition to validating the C to C++ transition, there's benefit in that for any future libgomp patches that affect 'libgomp/libgomp.map', this 'make check-abi' adds some (limited, but still) automated verification, in addition to the manual review that we currently do. >From a (very) quick look, the existing infrastructure in libstdc++ should be portable/generalizable for libgomp in a reasonable way. What do you think? Good idea, or overkill for this purpose? Grüße Thomas > I think we also want to keep the current ABI between libgomp and the libgomp > plugins. > > The main first purpose is just to allow the template code > > template <bool ompt> > ... > > and then use the two variants, notinlined + OMPT callback processing and > inlined non-OMPT callback processing. > > > I assume as time passes, cleanup and adding new OpenMP features means that > more C++ gets used, including C++ mangling inside libgomp, which is obviously > fine. > > Tobias
