Re: Transitioning libgomp from C to C++ implementation

Am Samstag, dem 09.05.2026 um 11:08 +0200 schrieb Arsen Arsenović:
> Martin Uecker <[email protected]> writes:
> 
> > What I find unlucky, for example, is that we do have a generic
> > tree data structure with a lot of imlicit assumptions and lot
> > of issues if those are violated. So encapsulating this properly
> > in abstract data types would be really helpful.  But we could do
> > this also in C, while the switch to C++ apparently did nothing
> > to address this.
> 
> Indeed, adding '-x c++' doesn't automatically fix existing code.
> 
> However, C++ enables other things to be done here.  For instance, at
> one of the Office Hours, a mechanism for encoding tree types (without
> requiring rewriting massive amounts of code) was proposed.  It relied on
> templates, and it compiles down to the same code as today, and can
> provide a bridge for existing code.  Essentially, it allowed us to
> specify types such as 'ttree<one_of<PLUS_EXPR, MINUS_EXPR>>' or such,
> and could automatically insert (and elide) gcc_asserts that check for
> those tree codes.
> 
> I don't recall who proposed it or if it ever was sent, but a similar
> thing wouldn't be possible in C.

It isn't clear to me what that removing gcc_asserts by a complicated
type (that then may be hidden behind "auto" because typing it out
is to cumbersome) is necessarily an improvement.


The issue with C++ is that people get overly excited about
the impressive capabilities of the language (and don't get me wrong,
there was a time in my life where I was too!), and in toy examples
this always looks cool,  but then if you look at actual code in
a larger project it is often much harder to understand.

What we would need in my opinion would be simply

struct expression;
struct type;
struct statement;
etc.

wrappers aroung tree nodes and a set of helpers function to operate on
such data types without breaking their invariants, nothing more and
nothing less.

In C FE it looks somebody was starting to introduce such wrappers,
but apparently never made a lot of progress. 


But anyhow, we do not need to discuss this further. I only wanted to point
out that for libubsan some people would be more happy with a lean C version,
and raise the question whether this is relevant for libgomp or not. 


Martin


> 
> It looked like something I sketched at one point, but I never finished
> the implementation, unfortunately, so there's nothing for me to share.
> Apologies.