Transitioning libgomp from C to C++ implementation

Transitioning libgomp from C to C++ implementation

[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), 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

Transitioning libgomp from C to C++ implementation: untyped 'gomp_malloc' etc.

[Thomas Schwinge]

Hi!

On 2026-05-07T13:16:59+0200, I wrote:
> 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.

So, first item: what do we do with the untyped 'gomp_malloc' etc.?
'libgomp/libgomp.h':

    extern void *gomp_malloc (size_t) __attribute__((malloc));

..., and a good number of similar others.

My current assumption is that we leave these untyped, do not templatize
them?

In other words, we'll need some kind of type casting at each call site:

    gomp_mutex_t *plock;
    [...]
    plock = gomp_malloc (sizeof (gomp_mutex_t));

I could already in the C implementation make that:

    plock = (gomp_mutex_t *) gomp_malloc (sizeof (gomp_mutex_t));

..., or (preferably?):

    plock = (typeof (plock)) gomp_malloc (sizeof (gomp_mutex_t));

Such changes could go in already now, in the C code.  However, I assume
that we'd eventually like this to be proper C++:

    plock = static_cast<decltype(plock)>(gomp_malloc (sizeof (gomp_mutex_t)));

..., or not?  If yes, then all those numerous changes have to be part of
the C++ switch commit.

In the external header files ('omp.h', 'openacc.h', etc.), I guess we'll
just continue to use C-style casts for C/C++ compatibility, or some:

    #ifdef __cplusplus
    # define STATIC_CAST(T, x) static_cast<T>(x)
    #else
    # define STATIC_CAST(T, x) ((T) (x))
    #endif

..., but I'd like to avoid that in libgomp implementation and internal
headers files, and instead make the proper C++?

Anyone have any strong preferences or other yet other suggestions?


On the other hand, we already have code like this:

    gomp_mutex_t *nlock = (gomp_mutex_t *) gomp_malloc (sizeof (gomp_mutex_t));

..., which should continue to work for C++ compilation, via the C-style
cast, but I assume that we'd also switch those to the agreed C++-style?


Grüße
 Thomas

Re: Transitioning libgomp from C to C++ implementation

[Richard Biener]

> Am 07.05.2026 um 13:18 schrieb Thomas Schwinge <tschwinge@baylibre.com>:
> 
> 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.

Do you plan there to be changes of the ABI and thus GCCs middle-end interfacing?

Richard 

> 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

Re: Transitioning libgomp from C to C++ implementation

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

Thomas Schwinge wrote:
> 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.
...
> most recently in context of an upcoming OpenMP OMPT
> implementation […], 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

Two notes:

* First, OMPT implementation work is currently being under way; hence,
   it makes sense that the C++ is available once the changes are ready
   to land. – The Boolean templates are supposed to get resolved at
   compile time at call side. Such that the non-OMPT implementation is
   inlined - while the OMPT callback version is a non-inlined static
   function, invoked if the tool of the user registered a callback for
   that feature.
   Benchmarking an OMPT implementation showing that while for most
   functions, just having an 'if' around the callback handling, for
   some code, there is a measurable slow down; thus, for for those
   the inlining + function call makes sense - and templates make it
   easy to avoid code duplications in a readable way.

* Second, the idea is that for now neither exceptions nor RTTY are
   used/enabled and that no additionally library dependency like to
   libstdc++ is added, i.e. the idea is to enable only some C++ features
   without adding any runtime overhead or runtime dependency.

For OMPT, the idea is also to be able to disable all OMPT completely
('#ifndef') - for all targets that don't support it (or the user
compiling GCC does not want to have it).

In terms of compatibility: This changes requires that all systems that
want to use (thread-based) OpenMP - and, hence, libgomp have support
the C++ compiler - but in terms of target capabilities, this shouldn't
require and additional features than C.

Tobias

Re: Transitioning libgomp from C to C++ implementation

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

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;
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

Re: Transitioning libgomp from C to C++ implementation: untyped 'gomp_malloc' etc.

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

Hi,

Thomas Schwinge wrote:
> So, first item: what do we do with the untyped 'gomp_malloc' etc.?
> 'libgomp/libgomp.h':
>      extern void *gomp_malloc (size_t) __attribute__((malloc));
...
> In other words, we'll need some kind of type casting at each call site:
> I could already in the C implementation make that:
>
>      plock = (gomp_mutex_t *) gomp_malloc (sizeof (gomp_mutex_t));
> ..., or (preferably?):
>      plock = (typeof (plock)) gomp_malloc (sizeof (gomp_mutex_t));

well, while 'typeof' is C23, 'decltype' is C++11 while __typeof__ works
as compiler extension with both GCC's C and C++ compiler.

An alternative to the explicit cast would be what we do inside GCC itself,
namely to use a macro:

libiberty.h:#define XCNEW(T)            ((T *) xcalloc (1, sizeof (T)))
libiberty.h:#define XCNEWVEC(T, N)              ((T *) xcalloc ((N), sizeof (T)))
libiberty.h:#define XCNEWVAR(T, S)              ((T *) xcalloc (1, (S)))

which could be used as is – or with T on the RHS replaced by
__typeof__(T) which then works with both type names and variable names.

> Such changes could go in already now, in the C code.  However, I assume
> that we'd eventually like this to be proper C++:
>
>      plock = static_cast<decltype(plock)>(gomp_malloc (sizeof (gomp_mutex_t)));

I think one can discuss whether '(T)' is also proper C++ or only 'static_cast<T>'.

(the static_case one makes it longer and hence less readable but is more
explicit and C++-ize.)

* * *

> In the external header files ('omp.h', 'openacc.h', etc.), I guess we'll
> just continue to use C-style casts for C/C++ compatibility, or some:
>
>      #ifdef __cplusplus
>      # define STATIC_CAST(T, x) static_cast<T>(x)
>      #else
>      # define STATIC_CAST(T, x) ((T) (x))
>      #endif

Why do you need to touch the external files at all? Those should already
be working with both C and C++? (BTW: There is some C++ only code in omp.h
as std::allocator replacement.)

And for casts, you don't even get something better by using static_cast
via a macro. - I see the argument of using it with explicitly written
code but here?

And when later moving to static_cast<...>(...) as cleanup, you need to
touch all call sides already you might need to adjust indentation anyway.

* * *

For a step-wise conversion, I think either using a macro version, similar
to libiberty.h or using the C-style cast makes sense.

And later, we can still decide whether doing style changes, but I think
this cast is not really the most important change for clarity, type safety
or similar reasons.

Tobias

Re: Transitioning libgomp from C to C++ implementation: untyped 'gomp_malloc' etc.

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 3743 bytes --]

Thomas Schwinge <tschwinge@baylibre.com> writes:

> Hi!
>
> On 2026-05-07T13:16:59+0200, I wrote:
>> 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.
>
> So, first item: what do we do with the untyped 'gomp_malloc' etc.?
> 'libgomp/libgomp.h':
>
>     extern void *gomp_malloc (size_t) __attribute__((malloc));
>
> ..., and a good number of similar others.
>
> My current assumption is that we leave these untyped, do not templatize
> them?
>
> In other words, we'll need some kind of type casting at each call site:
>
>     gomp_mutex_t *plock;
>     [...]
>     plock = gomp_malloc (sizeof (gomp_mutex_t));
>
> I could already in the C implementation make that:
>
>     plock = (gomp_mutex_t *) gomp_malloc (sizeof (gomp_mutex_t));
>
> ..., or (preferably?):
>
>     plock = (typeof (plock)) gomp_malloc (sizeof (gomp_mutex_t));
>
> Such changes could go in already now, in the C code.  However, I assume
> that we'd eventually like this to be proper C++:
>
>     plock = static_cast<decltype(plock)>(gomp_malloc (sizeof (gomp_mutex_t)));
>
> ..., or not?  If yes, then all those numerous changes have to be part of
> the C++ switch commit.

No, we can implement an 'operator new' overload for it:

  struct gomp_malloc_tag {};
  gomp_malloc_tag use_gomp_malloc;

  void *
  operator new (std::size_t sz, gomp_malloc_tag)
  { return gomp_malloc (sz); }

  /* called as: new (use_gomp_malloc) T{} */

... , or even just make a:

  template<typename T, typename... Args>
  auto gomp_new (Args&&... args)
  { return new (gomp_malloc (sizeof (T))) T (std::forward<Args> (args)...); }

  /* gomp_new<gomp_thing> () */

... or such.  (didn't try either snippet, but both should be mostly
right.  Maybe even plain 'new' works and we can drop 'gomp_malloc' usage
altogether, given that we should be able to link libsupc++; that should
throw in case of being out of memory, and, since we have no exceptions,
crash, I think?)

See https://en.cppreference.com/cpp/memory/new/operator_new

Note that it's not always correct to do the static_cast you suggested.
The object lifetime does not begin if you do that.  It would also mean
that we lose the possibility of using constructors, which is also among
the biggest benefits of using C++.

We *could* also just do:

  T *x = new (gomp_malloc (sizeof (T))) T;

... of course, but that's clunkier.

> In the external header files ('omp.h', 'openacc.h', etc.), I guess we'll
> just continue to use C-style casts for C/C++ compatibility, or some:
>
>     #ifdef __cplusplus
>     # define STATIC_CAST(T, x) static_cast<T>(x)
>     #else
>     # define STATIC_CAST(T, x) ((T) (x))
>     #endif
>
> ..., but I'd like to avoid that in libgomp implementation and internal
> headers files, and instead make the proper C++?
>
> Anyone have any strong preferences or other yet other suggestions?

What code is there in headers in the existing C API that'd require this?
I do not recall any.

>
> On the other hand, we already have code like this:
>
>     gomp_mutex_t *nlock = (gomp_mutex_t *) gomp_malloc (sizeof (gomp_mutex_t));
>
> ..., which should continue to work for C++ compilation, via the C-style
> cast, but I assume that we'd also switch those to the agreed C++-style?

Yes, these need to be replaced also.  Not just for style.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: Transitioning libgomp from C to C++ implementation: untyped 'gomp_malloc' etc.

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

Arsen Arsenović wrote:
> ... or such.  (didn't try either snippet, but both should be mostly
> right.  Maybe even plain 'new' works and we can drop 'gomp_malloc' usage
> altogether, given that we should be able to link libsupc++; that should
> throw in case of being out of memory, and, since we have no exceptions,
> crash, I think?)

I think you don't mean crash but abort. - However, the whole point of
gomp_malloc is to avoid crashes without diagnostic in the
failue case. Hence, the current code reads as:

void *
gomp_malloc (size_t size)
{
   void *ret = malloc (size);
   if (ret == NULL)
     gomp_fatal ("Out of memory allocating %lu bytes", (unsigned long) size);
   return ret;
}

* * *

In any case, I think it probably makes most sense to do '(type)' style
first - being compatible with C and C++ - and once everything is converted,
we can still think about how to handle it best as cleanup step.

Tobias

Re: Transitioning libgomp from C to C++ implementation: untyped 'gomp_malloc' etc.

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2624 bytes --]

Tobias Burnus <tburnus@baylibre.com> writes:

> Arsen Arsenović wrote:
>> ... or such.  (didn't try either snippet, but both should be mostly
>> right.  Maybe even plain 'new' works and we can drop 'gomp_malloc' usage
>> altogether, given that we should be able to link libsupc++; that should
>> throw in case of being out of memory, and, since we have no exceptions,
>> crash, I think?)
>
> I think you don't mean crash but abort. - However, the whole point of
> gomp_malloc is to avoid crashes without diagnostic in the
> failue case. Hence, the current code reads as:

Yes, the diagnostic is not pretty:

  /tmp$ gcc -fno-exceptions -x c++ - <<<'int main() { while (1) new int{}; }' -lsupc++
  /tmp$ ulimit -v $((32*1024))
  /tmp$ ./a.out 
  terminate called after throwing an instance of 'St9bad_alloc'
    what():  std::bad_alloc
  Aborted                    (core dumped) ./a.out
  /tmp 134 $ 

... that's why I added two more suggestions (but it is semantically
equivalent, which is why I mention it at all).

> void *
> gomp_malloc (size_t size)
> {
>   void *ret = malloc (size);
>   if (ret == NULL)
>     gomp_fatal ("Out of memory allocating %lu bytes", (unsigned long) size);
>   return ret;
> }
>
> * * *
>
> In any case, I think it probably makes most sense to do '(type)' style
> first - being compatible with C and C++ - and once everything is converted,
> we can still think about how to handle it best as cleanup step.

As mentioned, that isn't necessarily compatible with C++, for types that
require some initialization.  Which should, hopefully, be most types, as
we phase in constructors.

Is there a reason C compatibility in the newly-C++ sources is a concern?
I can't think of any.  I can see the need for it in omp{,_lib}.h, but
not the internal sources (or even libgomp*.h)

If not, IMO it's better to avoid needing future churn, given that we can
make the 'new_...' helper (and, on that note, we should probably also
slowly phase in std::unique_ptr but that's not needed in the initial
conversion pass, and it'd make it harder to review, but a helper type
like:


  template<typename T>
  struct gomp_freeer
  {
      /* static */ void operator() (T* t)
      { /*gomp_*/free (static_cast<void *> (t)); }
  };
  
  template<typename T>
  using unique_ptr = std::unique_ptr<T, gomp_freeer<T>>;
  
  template<typename T, typename... Args>
  unique_ptr<T>
  make_unique (Args&&... args)
  { return unique_ptr<T> (new (/*gomp_*/malloc (sizeof (T))) T(std::forward<Args>(args)...)); }


... would work).
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: 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

Re: Transitioning libgomp from C to C++ implementation

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

Martin Uecker <muecker@gwdg.de> writes:

> I am not convinced that moving to C++ actually makes code more
> type safe or otherwise better.  

It certainly does, by providing a way to implement type-safe containers
for instance, and by providing generic mechanisms of initialization and
cleanup.

These do not require the standard library to be benefited from, even.

> 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. 

That's a strange choice, given that all compilers that implement ubsan
also implement C++ (to my awareness).

Perhaps there are other factors at play, such as libsanitizer not being
possible to compile in a given environment.

Indeed, that's why e.g. Managarm has a C++ reimplementation of libubsan
and friends for its kernel:
https://github.com/managarm/managarm/blob/master/kernel/thor/generic/ubsan.cpp
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 430 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Christopher Bazley]

On 08/05/2026 06:38, Martin Uecker via Gcc wrote:
> 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

I haven't worked on libgomp, but I agree with Martin's points.

A lot of compilers can plausibly support modern C that will never 
support modern C++. Modern C offers features for convenience (e.g. auto) 
and macro-based polymorphism (e.g. _Generic). Subtype polymorphism is 
more limited than in C++ but still achievable with a reasonable degree 
of type safety.

The issue with malloc seems to me like a canary in the coal mine. I 
don't know whether libgomp makes significant use of callback functions 
and event handlers, but they are likely to suffer from similar issues. 
If the return type of malloc is perceived to be a problem, then it is 
trivial to write a wrapper macro, e.g.

// https://godbolt.org/z/x58s8qMG3
#include <stdlib.h>

#define NEW(T) ((typeof(T) *)malloc(sizeof (T)))
#define NEW_ARRAY(T, N) ((typeof(T) *)malloc(sizeof (T) * (N)))
#define FOR_EACH(IT, AR) for (size_t IT = 0; IT < _Countof (AR); ++IT)

int main(int argc, const char *argv[static argc + 1])
{
     auto i = NEW(int [10]);
     if (i)
         (*i)[1] = 1;

     auto j = NEW_ARRAY(int, 10);
     if (j)
         j[3] = 2;

     auto k = NEW_ARRAY(typeof(argv[0]), argc);
     if (k)
         for (size_t l = 0; l < argc; ++l)
             k[l] = argv[l];

     auto m = NEW(typeof(argv[0]) [argc]);
     if (m)
         FOR_EACH(l, *m)
             (*m)[l] = argv[l];

     free(i);
     free(j);
     free(k);
     free(m);
}


C projects 'upgraded' to C++ can end up worse than reasonable code 
written from scratch according to good idioms of either language, due to:

- C++'s overly strict type rules concerning void *. Without care, C++'s 
type system has the ironic effect of making code *less* type-safe. (For 
the same reason that it would be less type-safe for MyPy to require 
explicit conversion of 'Any' to some other type.)

- C++ constructors being unable to return a failure indication, and the 
gymnastics required to work around that without using exceptions 
(leading to many identically-named construction helpers).

- Erasure of designated initialisers that were vital for keeping the 
code readable and maintainable (by preventing definitions, for example 
array initialisers and enumerations, from diverging).

- Gratuitous loss of the ability to find method definitions and usages 
using simple tools like 'grep'. (I do not mean gratuitous as a 
perjorative but in the specific sense that some useful patterns require 
subtype polymorphism, in which case the equivalent C code would have the 
same issue, but most code does not.)

As I said, I'm not familiar with libgomp, so I have no idea how much it 
might benefit in areas where C++ truly does excel, such as object 
lifetime management. In my experience, few C projects have complex 
object lifetimes (by design), but maybe libgomp is one of them.

Lastly, some C programmers are put off contributing to C++ codebases. I 
don't know how common the converse is.

Ultimately, it's up to the maintainers to decide. Good luck!

-- 
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/

Re: Transitioning libgomp from C to C++ implementation

[Christopher Bazley]

On 08/05/2026 09:48, Arsen Arsenović wrote:
> Martin Uecker <muecker@gwdg.de> writes:
> 
>> I am not convinced that moving to C++ actually makes code more
>> type safe or otherwise better.
> 
> It certainly does, by providing a way to implement type-safe containers
> for instance, and by providing generic mechanisms of initialization and
> cleanup.
There are many implementations of type-safe containers in C (including 
Martin's). Whether those solutions would meet your expectations is 
another question.

It's tempting to think of type-safe vs. non-type-safe as a binary 
choice, but I think there are degrees of type safety. In my opinion, the 
de facto standard CONTAINER_OF() macro is type-safe enough to all 
intents and purposes.

C++'s templates undoubtedly provide a more powerful facility than the 
preprocessor, but some of us like being able to inspect and reason about 
preprocessed translation units.

The simplest way of implementing type-safe containers in C is to follow 
the precedent set by NDEBUG and predefine macros to the value of any 
required parameters before including any source files that require 
parametric polymorphism. This also offers the easiest and most 
straightforward migration path from monomorphic to polymorphic code.

-- 
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/

Re: Transitioning libgomp from C to C++ implementation

[Martin Uecker]

Am Freitag, dem 08.05.2026 um 10:48 +0200 schrieb Arsen Arsenović:
> Martin Uecker <muecker@gwdg.de> writes:
...

> 
> > 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. 
> 
> That's a strange choice, given that all compilers that implement ubsan
> also implement C++ (to my awareness).
> 
> Perhaps there are other factors at play, such as libsanitizer not being
> possible to compile in a given environment.
> 
> Indeed, that's why e.g. Managarm has a C++ reimplementation of libubsan
> and friends for its kernel:
> https://github.com/managarm/managarm/blob/master/kernel/thor/generic/ubsan.cpp

I am not sure what the reason was why libsanitizer could not be used,
but I would suspect that this was also caused by some complexity related
to C++.   

A C library you can usually be used everywhere without much trouble,
including various kernel, embedded, and free-standing contexts. So
this usually provides more value to users.  This may be irrelevant for
libgomp though.

Martin

Re: Transitioning libgomp from C to C++ implementation

[Alex (Waffl3x)]

On Fri, May 8, 2026 at 3:51 AM Martin Uecker <muecker@gwdg.de> wrote:
>
> A C library you can usually be used everywhere without much trouble,
> including various kernel, embedded, and free-standing contexts. So
> this usually provides more value to users.  This may be irrelevant for
> libgomp though.
>
> Martin

C++ supports specifying language linkage with extern "C", the interface
of a library does not need to match its implementation. Which is also
what is being proposed here to avoid breaking ABI.

Alex

Re: Transitioning libgomp from C to C++ implementation

[Martin Uecker]

Am Freitag, dem 08.05.2026 um 06:23 -0600 schrieb Alex (Waffl3x):
> On Fri, May 8, 2026 at 3:51 AM Martin Uecker <muecker@gwdg.de> wrote:
> > 
> > A C library you can usually be used everywhere without much trouble,
> > including various kernel, embedded, and free-standing contexts. So
> > this usually provides more value to users.  This may be irrelevant for
> > libgomp though.
> > 
> > Martin
> 
> C++ supports specifying language linkage with extern "C", the interface
> of a library does not need to match its implementation. Which is also
> what is being proposed here to avoid breaking ABI.

I understand this, but this is true also for libubsan and still people
reimplement libubsan in C because the C++ version does not seem to fit
their needs. I do not know the exact reasons, and I am also not sure those
would apply to libgomp.

Martin



> 
> Alex

Re: Transitioning libgomp from C to C++ implementation

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Martin Uecker <muecker@gwdg.de> writes:

> I understand this, but this is true also for libubsan and still people
> reimplement libubsan in C because the C++ version does not seem to fit
> their needs. I do not know the exact reasons, and I am also not sure
> those would apply to libgomp.

Without knowing specifics, I'd wager that's more likely to be due to
libsanitizers than C++.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 430 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Richard Earnshaw (foss)]

On 08/05/2026 13:23, Alex (Waffl3x) wrote:
> On Fri, May 8, 2026 at 3:51 AM Martin Uecker <muecker@gwdg.de> wrote:
>>
>> A C library you can usually be used everywhere without much trouble,
>> including various kernel, embedded, and free-standing contexts. So
>> this usually provides more value to users.  This may be irrelevant for
>> libgomp though.
>>
>> Martin
> 
> C++ supports specifying language linkage with extern "C", the interface
> of a library does not need to match its implementation. Which is also
> what is being proposed here to avoid breaking ABI.
> 
> Alex

That may not be enough if you end up depending on libstdc++ during linking.

R.

Re: Transitioning libgomp from C to C++ implementation

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

"Richard Earnshaw (foss)" <Richard.Earnshaw@arm.com> writes:

> On 08/05/2026 13:23, Alex (Waffl3x) wrote:
>> On Fri, May 8, 2026 at 3:51 AM Martin Uecker <muecker@gwdg.de> wrote:
>>>
>>> A C library you can usually be used everywhere without much trouble,
>>> including various kernel, embedded, and free-standing contexts. So
>>> this usually provides more value to users.  This may be irrelevant for
>>> libgomp though.
>>>
>>> Martin
>> 
>> C++ supports specifying language linkage with extern "C", the interface
>> of a library does not need to match its implementation. Which is also
>> what is being proposed here to avoid breaking ABI.
>> 
>> Alex
>
> That may not be enough if you end up depending on libstdc++ during linking.

As mentioned initially, there's no intention to depend on libstdc++.
IMO this is a bit dubious but it's not important enough to bikeshed
over.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 300 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 4483 bytes --]

Christopher Bazley <chris.bazley@arm.com> writes:

> I haven't worked on libgomp, but I agree with Martin's points.
>
> A lot of compilers can plausibly support modern C that will never
> support modern C++.

libgomp is a GCC runtime library.  The only compiler of concern is GCC.

> Modern C offers features for convenience (e.g. auto) and macro-based
> polymorphism (e.g. _Generic). Subtype polymorphism is more limited
> than in C++ but still achievable with a reasonable degree of type
> safety.

Yet, it offers no destructors, and no move semantics, which are arguably
the most important features of C++11 and onwards.  I'd trade _Generic
for those two, and make it out of the deal like a bandit.

> The issue with malloc seems to me like a canary in the coal mine. I
> don't know whether libgomp makes significant use of callback functions
> and event handlers, but they are likely to suffer from similar
> issues. If the return type of malloc is perceived to be a problem,
> then it is trivial to write a wrapper macro, e.g.

I don't see what issue that is.  Previously, allocation and
initialization were separate.  They aren't in C++.  I don't see how that
could apply to either callbacks or event handlers.

(Note that every single instance of an allocation in libgomp falls under
 the case of trivial initialization by merit of being a C codebase, and
 ergo, even the initially-proposed mechanical conversion of allocation
 sites is not incorrect, just presumably inconsistent with newer code)

> C projects 'upgraded' to C++ can end up worse than reasonable code
> written from scratch according to good idioms of either language, due
> to:

Yes, this isn't surprising.  That's exactly why I was arguing not to do
mechanical explicit void* casts in the cases where memcpy is immediately
followed by initialization.

The instances where allocating uninitialized memory is genuinely useful
are in the tiny minority, but they do exist in libgomp.  These need to
still call malloc explicitly with a computed size, as in C.

There are also a number of useful flexible array members, but for these,
each such type can provide an allocation-and-construction helper.

> - C++'s overly strict type rules concerning void *. Without care, C++'s type
>   system has the ironic effect of making code *less* type-safe. (For the same
>   reason that it would be less type-safe for MyPy to require explicit
>  conversion of 'Any' to some other type.)

?  Those rules aren't overly strict.  I don't follow how this analogy
with 'Any' demonstrates a lowering of type safety.

> - C++ constructors being unable to return a failure indication, and the
>   gymnastics required to work around that without using exceptions (leading to
>  many identically-named construction helpers).

I've been writing C++ in places where exceptions would be inconvenient
for many years now, and this is a fairly infrequent requirement IME.

It will be fine.

> - Erasure of designated initialisers that were vital for keeping the code
>   readable and maintainable (by preventing definitions, for example array
>  initialisers and enumerations, from diverging).

Designated initializers exist in C++.

> - Gratuitous loss of the ability to find method definitions and usages using
>   simple tools like 'grep'. (I do not mean gratuitous as a perjorative but in
>   the specific sense that some useful patterns require subtype polymorphism, in
>   which case the equivalent C code would have the same issue, but most code
>  does not.)

There's no C pattern that is impossible in C++.  There's certainly
nothing that requires dynamic dispatch that wouldn't require a
(hand-rolled) vtable in C.

Do note, however, that such a table exists in libgomp already:
https://gcc.gnu.org/cgit/gcc/tree/libgomp/libgomp.h#n1391

> As I said, I'm not familiar with libgomp, so I have no idea how much
> it might benefit in areas where C++ truly does excel, such as object
> lifetime management. In my experience, few C projects have complex
> object lifetimes (by design), but maybe libgomp is one of them.

Trivial objects still benefit from destructors.  unique_ptr is a
distilled example.

> Lastly, some C programmers are put off contributing to C++
> codebases. I don't know how common the converse is.

Given that gcc is already in C++, it seems that that bridge was burned.

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 288 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Arsen Arsenović via Gcc <gcc@gcc.gnu.org> writes:

> Christopher Bazley <chris.bazley@arm.com> writes:
> [...]
>> - Erasure of designated initialisers that were vital for keeping the code
>>   readable and maintainable (by preventing definitions, for example array
>>  initialisers and enumerations, from diverging).
>
> Designated initializers exist in C++.

I was going to say "you won't be using C++20 yet, though", but I suppose
you may be able to as it's a runtime library.

>> Lastly, some C programmers are put off contributing to C++
>> codebases. I don't know how common the converse is.
>
> Given that gcc is already in C++, it seems that that bridge was burned.

Also, I don't think libgomp often gets external contributions anyway.

> [...]

sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

Sam James <sam@gentoo.org> writes:

> I was going to say "you won't be using C++20 yet, though", but I suppose
> you may be able to as it's a runtime library.

It's stable and default now:

  ~$ g++ -E -o - -x c++ -dM - <<<'' | grep __cplusplus
  #define __cplusplus 202002L
  ~$ g++ -std=c++20 -E -o - -x c++ -dM - <<<'' | grep __cplusplus
  #define __cplusplus 202002L

Since it's a runtime library, we don't need to worry about bootstrap
requirements there (ergo why the code has quite a few extensions
peppered throughout as it stands).
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 288 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Martin Uecker]

Am Freitag, dem 08.05.2026 um 20:06 +0200 schrieb Arsen Arsenović via Gcc:
> Christopher Bazley <chris.bazley@arm.com> writes:
> 
...
> 
> > Lastly, some C programmers are put off contributing to C++
> > codebases. I don't know how common the converse is.
> 
> Given that gcc is already in C++, it seems that that bridge was burned.

Sadly this is true, once you add complexity, it is much more
difficult to get rid of it again. Entropy...

Luckily, a large part of gcc is still quite C-like, but I also
wonder sometimes whether I should focus my time elsewhere
given the trends.


Best,
Martin

Re: Transitioning libgomp from C to C++ implementation: untyped 'gomp_malloc' etc.

[Jonathan Wakely]

On Thu, 7 May 2026 at 16:59, Arsen Arsenović via Gcc <gcc@gcc.gnu.org> wrote:
>
> Thomas Schwinge <tschwinge@baylibre.com> writes:
>
> > Hi!
> >
> > On 2026-05-07T13:16:59+0200, I wrote:
> >> 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.
> >
> > So, first item: what do we do with the untyped 'gomp_malloc' etc.?
> > 'libgomp/libgomp.h':
> >
> >     extern void *gomp_malloc (size_t) __attribute__((malloc));
> >
> > ..., and a good number of similar others.
> >
> > My current assumption is that we leave these untyped, do not templatize
> > them?
> >
> > In other words, we'll need some kind of type casting at each call site:
> >
> >     gomp_mutex_t *plock;
> >     [...]
> >     plock = gomp_malloc (sizeof (gomp_mutex_t));
> >
> > I could already in the C implementation make that:
> >
> >     plock = (gomp_mutex_t *) gomp_malloc (sizeof (gomp_mutex_t));
> >
> > ..., or (preferably?):
> >
> >     plock = (typeof (plock)) gomp_malloc (sizeof (gomp_mutex_t));
> >
> > Such changes could go in already now, in the C code.  However, I assume
> > that we'd eventually like this to be proper C++:
> >
> >     plock = static_cast<decltype(plock)>(gomp_malloc (sizeof (gomp_mutex_t)));
> >
> > ..., or not?  If yes, then all those numerous changes have to be part of
> > the C++ switch commit.
>
> No, we can implement an 'operator new' overload for it:
>
>   struct gomp_malloc_tag {};
>   gomp_malloc_tag use_gomp_malloc;
>
>   void *
>   operator new (std::size_t sz, gomp_malloc_tag)

If you declare this as noexcept then that means that it signals
failure to allocate by returning null, instead of throwing an
exception. And then callers (including the compiler when invoking it
for a new-expression) check for a null pointer, instead of having to
handle a std::bad_alloc exception.

But since gomp_malloc never fails anyway (it either returns non-null
or aborts the process with a diagnostic?) there's no need to worry
about exceptions here.

So the operator above would allow:

auto ptr = new (use_gomp_malloc) SomeType(args);

and you'd get a call to gomp_malloc with the right size, followed by a
call to the SomeType constructor.

Re: Transitioning libgomp from C to C++ implementation

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Martin Uecker <muecker@gwdg.de> writes:

> Sadly this is true, once you add complexity, it is much more
> difficult to get rid of it again. Entropy...
>
> Luckily, a large part of gcc is still quite C-like, but I also
> wonder sometimes whether I should focus my time elsewhere
> given the trends.

I find that condition quite unlucky myself.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Martin Uecker]

Am Samstag, dem 09.05.2026 um 01:03 +0200 schrieb Arsen Arsenović:
> Martin Uecker <muecker@gwdg.de> writes:
> 
> > Sadly this is true, once you add complexity, it is much more
> > difficult to get rid of it again. Entropy...
> > 
> > Luckily, a large part of gcc is still quite C-like, but I also
> > wonder sometimes whether I should focus my time elsewhere
> > given the trends.
> 
> I find that condition quite unlucky myself.

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.


Martin

Re: Transitioning libgomp from C to C++ implementation

[Christopher Bazley]

Hi Arsen,

On 08/05/2026 19:06, Arsen Arsenović wrote:
> Christopher Bazley <chris.bazley@arm.com> writes:
> 
>> I haven't worked on libgomp, but I agree with Martin's points.
>>
>> A lot of compilers can plausibly support modern C that will never
>> support modern C++.
> 
> libgomp is a GCC runtime library.  The only compiler of concern is GCC.
> 
>> Modern C offers features for convenience (e.g. auto) and macro-based
>> polymorphism (e.g. _Generic). Subtype polymorphism is more limited
>> than in C++ but still achievable with a reasonable degree of type
>> safety.
> 
> Yet, it offers no destructors, and no move semantics, which are arguably
> the most important features of C++11 and onwards.  I'd trade _Generic
> for those two, and make it out of the deal like a bandit.

OK. If that's what libgomp needs, then that's what makes sense. If what 
libgomp needed were ad hoc polymorphism, then _Generic would be 
perfectly adequate.

>> The issue with malloc seems to me like a canary in the coal mine. I
>> don't know whether libgomp makes significant use of callback functions
>> and event handlers, but they are likely to suffer from similar
>> issues. If the return type of malloc is perceived to be a problem,
>> then it is trivial to write a wrapper macro, e.g.
> 
> I don't see what issue that is.  Previously, allocation and
> initialization were separate.  They aren't in C++.  I don't see how that
> could apply to either callbacks or event handlers.

Callbacks and event handlers commonly have a parameter of type 'void *'. 
Requiring arguments of that type to be explicitly cast to some other 
pointer type makes source code harder to read and write, and actually 
detracts from type safety.

> (Note that every single instance of an allocation in libgomp falls under
>   the case of trivial initialization by merit of being a C codebase, and
>   ergo, even the initially-proposed mechanical conversion of allocation
>   sites is not incorrect, just presumably inconsistent with newer code)
> 
>> C projects 'upgraded' to C++ can end up worse than reasonable code
>> written from scratch according to good idioms of either language, due
>> to:
> 
> Yes, this isn't surprising.  That's exactly why I was arguing not to do
> mechanical explicit void* casts in the cases where memcpy is immediately
> followed by initialization.
> 
> The instances where allocating uninitialized memory is genuinely useful
> are in the tiny minority, but they do exist in libgomp.  These need to
> still call malloc explicitly with a computed size, as in C.
> 
> There are also a number of useful flexible array members, but for these,
> each such type can provide an allocation-and-construction helper.
> 
>> - C++'s overly strict type rules concerning void *. Without care, C++'s type
>>    system has the ironic effect of making code *less* type-safe. (For the same
>>    reason that it would be less type-safe for MyPy to require explicit
>>   conversion of 'Any' to some other type.)
> 
> ?  Those rules aren't overly strict.  I don't follow how this analogy
> with 'Any' demonstrates a lowering of type safety.

Casting discards type information. Preventing implicit conversion of 
type 'void *' to other pointer types on assignment or initialisation 
prevents the compiler from checking that qualifiers weren't discarded, 
or even that the expression whose type is being cast actually has a 
pointer type.

For example:

void callback(const void *p)
{
   int *q = (int *)p; // whoops!
   *q = 1;
}

void callback(long int p)
{
   int *q = (int *)p; // whoops!
   *q = 1;
}

I believe that the concept of any-type (as expressed via void *) is 
orthogonal to the concept of qualified type or subtype. Python's 
treatment of the type annotation Any supports this point of view.

This flaw in the design of C++ is also what necessitated the invention 
of nullptr, which would otherwise be unnecessary. Had the purpose of 
'void *' not been misunderstood, nullptr could simply have been defined 
as a macro: ((void *)0).

>> - C++ constructors being unable to return a failure indication, and the
>>    gymnastics required to work around that without using exceptions (leading to
>>   many identically-named construction helpers).
> 
> I've been writing C++ in places where exceptions would be inconvenient
> for many years now, and this is a fairly infrequent requirement IME.
> 
> It will be fine.

Sorry but I'm not sure what you mean here.

Are you saying that wanting to return a failure indication is 
infrequent, that doing without exceptions is infrequent, or both? I 
guess it depends what kind of code you are writing and what kind of 
system it runs on.

Nowadays a lot of programmers would claim that malloc cannot fail, or at 
least that programs have no need to recover gracefully if it does fail. 
That does not apply to interactive programs running on operating systems 
that do not overcommit memory, but it might apply to non-interactive 
programs running on such systems.

>> - Erasure of designated initialisers that were vital for keeping the code
>>    readable and maintainable (by preventing definitions, for example array
>>   initialisers and enumerations, from diverging).
> 
> Designated initializers exist in C++.

Not usefully, as far as I can tell: https://godbolt.org/z/7j6fdqzrb
I find it frustrating that C++ lags more than a quarter of a century 
behind C in this respect. (I am aware why C++ does not allow arbitrary 
order of initialisers, but I do not see that as a point in its favour: 
debugging a mess caused by misordered  constructor and destructor 
invocations is not fun.)

>> - Gratuitous loss of the ability to find method definitions and usages using
>>    simple tools like 'grep'. (I do not mean gratuitous as a perjorative but in
>>    the specific sense that some useful patterns require subtype polymorphism, in
>>    which case the equivalent C code would have the same issue, but most code
>>   does not.)
> 
> There's no C pattern that is impossible in C++.  There's certainly
> nothing that requires dynamic dispatch that wouldn't require a
> (hand-rolled) vtable in C.

The issue is not impossibility but reduced maintainability of code that 
has fewer unique identifiers. It's possible to similarly reduce the 
maintainability of C programs by using structs to implement namespaces, 
and invoking functions via members. Most C programmers consider that the 
downsides outweigh any advantages.

> Do note, however, that such a table exists in libgomp already:
> https://gcc.gnu.org/cgit/gcc/tree/libgomp/libgomp.h#n1391
> 
>> As I said, I'm not familiar with libgomp, so I have no idea how much
>> it might benefit in areas where C++ truly does excel, such as object
>> lifetime management. In my experience, few C projects have complex
>> object lifetimes (by design), but maybe libgomp is one of them.
> 
> Trivial objects still benefit from destructors.  unique_ptr is a
> distilled example.
> 
>> Lastly, some C programmers are put off contributing to C++
>> codebases. I don't know how common the converse is.
> 
> Given that gcc is already in C++, it seems that that bridge was burned.

It isn't as black and white as that. I know of at least one programmer 
who contributes to GCC because GCC is still largely written in the style 
of a C program, but does not feel inclined or able to contribute to 
Clang. He is probably unusual in that he is outspoken in his opinions.

> Have a lovely day.

You too.
-- 
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/

Re: Transitioning libgomp from C to C++ implementation

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

Martin Uecker <muecker@gwdg.de> 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 looked like something I sketched at one point, but I never finished
the implementation, unfortunately, so there's nothing for me to share.
Apologies.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 288 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Martin Uecker]

Am Samstag, dem 09.05.2026 um 11:08 +0200 schrieb Arsen Arsenović:
> Martin Uecker <muecker@gwdg.de> 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.

Re: Transitioning libgomp from C to C++ implementation

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 6727 bytes --]

Hi Cristopher,

Christopher Bazley <chris.bazley@arm.com> writes:

> OK. If that's what libgomp needs, then that's what makes sense. If
> what libgomp needed were ad hoc polymorphism, then _Generic would be
> perfectly adequate.

Scarce few programs have no need for those.  I can't think of many
programs that don't need lists but do need overloading.

> Callbacks and event handlers commonly have a parameter of type 'void
> *'. Requiring arguments of that type to be explicitly cast to some
> other pointer type makes source code harder to read and write, and
> actually detracts from type safety.

I see no difference between

  T *userptr = userptr_voidstar;

... and:

  auto userptr = static_cast<T *> (userptr_voidstar);

... in this regard.

In addition, unlike in C, it is possible to hide away the lossy type
games: https://godbolt.org/z/z5dzr93Eb

(the above is incomplete in a few obvious ways, but it's a quick sketch)

> Casting discards type information. Preventing implicit conversion of
> type 'void *' to other pointer types on assignment or initialisation
> prevents the compiler from checking that qualifiers weren't discarded,
> or even that the expression whose type is being cast actually has a
> pointer type.
>
> For example:
>
> void callback(const void *p)
> {
>   int *q = (int *)p; // whoops!
>   *q = 1;
> }
>
> void callback(long int p)
> {
>   int *q = (int *)p; // whoops!
>   *q = 1;
> }

Luckily neither of those are legal when using specific casts:

  ~$ g++ -S -o - -x c++ - <<< 'void f(const void *p) { auto x = static_cast<int *>(p); }'
  	.file	"<stdin>"
  <stdin>: In function ‘void f(const void*)’:
  <stdin>:1:34: error: ‘static_cast’ from type ‘const void*’ to type ‘int*’ casts away qualifiers
  ~ 1 $ g++ -S -o - -x c++ - <<< 'void f(long int p) { auto x = static_cast<int *>(p); }'
  	.file	"<stdin>"
  <stdin>: In function ‘void f(long int)’:
  <stdin>:1:31: error: invalid ‘static_cast’ from type ‘long int’ to type ‘int*’
  ~ 1 $ g++ -S -o - -x c++ - <<< 'void f(__UINTPTR_TYPE__ p) { auto x = static_cast<int *>(p); }'
  	.file	"<stdin>"
  <stdin>: In function ‘void f(long unsigned int)’:
  <stdin>:1:39: error: invalid ‘static_cast’ from type ‘long unsigned int’ to type ‘int*’
  ~ 1 $ 

> I believe that the concept of any-type (as expressed via void *) is orthogonal
> to the concept of qualified type or subtype. Python's treatment of the type
> annotation Any supports this point of view.
>
> This flaw in the design of C++ is also what necessitated the invention of
> nullptr, which would otherwise be unnecessary. Had the purpose of 'void *' not
> been misunderstood, nullptr could simply have been defined as a macro: ((void
> *)0).

OTOH, there's no benefit to omitting a 'nullptr' constant from the
language.

>>> - C++ constructors being unable to return a failure indication, and the
>>>    gymnastics required to work around that without using exceptions (leading to
>>>   many identically-named construction helpers).
>> I've been writing C++ in places where exceptions would be inconvenient
>> for many years now, and this is a fairly infrequent requirement IME.
>> It will be fine.
>
> Sorry but I'm not sure what you mean here.
>
> Are you saying that wanting to return a failure indication is
> infrequent, that doing without exceptions is infrequent, or both? I
> guess it depends what kind of code you are writing and what kind of
> system it runs on.

The former.

> Nowadays a lot of programmers would claim that malloc cannot fail, or
> at least that programs have no need to recover gracefully if it does
> fail. That does not apply to interactive programs running on operating
> systems that do not overcommit memory, but it might apply to
> non-interactive programs running on such systems.

Sure.  And very often, types that hold pointers (e.g. for smart
pointers) can encode such a fail state.  In cases where they cannot,
factory functions usually don't result in combinatorial explosion.

>>> - Erasure of designated initialisers that were vital for keeping the code
>>>    readable and maintainable (by preventing definitions, for example array
>>>   initialisers and enumerations, from diverging).
>> Designated initializers exist in C++.
>
> Not usefully, as far as I can tell: https://godbolt.org/z/7j6fdqzrb

I'm surprised GCC emits a sorry here, I hadn't noticed that.

> I find it frustrating that C++ lags more than a quarter of a century
> behind C in this respect. (I am aware why C++ does not allow arbitrary
> order of initialisers, but I do not see that as a point in its favour:
> debugging a mess caused by misordered constructor and destructor
> invocations is not fun.)

Such a "mess" is no different than the "mess" of relying on the
evaluation order of function arguments, except that in this case it's
more specified.

>>> - Gratuitous loss of the ability to find method definitions and usages using
>>>    simple tools like 'grep'. (I do not mean gratuitous as a perjorative but in
>>>    the specific sense that some useful patterns require subtype polymorphism, in
>>>    which case the equivalent C code would have the same issue, but most code
>>>   does not.)
>> There's no C pattern that is impossible in C++.  There's certainly
>> nothing that requires dynamic dispatch that wouldn't require a
>> (hand-rolled) vtable in C.
>
> The issue is not impossibility but reduced maintainability of code
> that has fewer unique identifiers. It's possible to similarly reduce
> the maintainability of C programs by using structs to implement
> namespaces, and invoking functions via members. Most C programmers
> consider that the downsides outweigh any advantages.

I find memorizing many redundant identifiers isn't much better.

A name should name equivalent behavior in all contexts.  A size is a
size.  A push_back is a push_back.  A pop_back is a pop_back.

>> Given that gcc is already in C++, it seems that that bridge was burned.
>
> It isn't as black and white as that. I know of at least one programmer who
> contributes to GCC because GCC is still largely written in the style of a C
> program, but does not feel inclined or able to contribute to Clang. He is
> probably unusual in that he is outspoken in his opinions.

Anecdotally, I've heard the opposite at least twice.

I have no doubt the phenomenon exists, but I am certain that the more
expressively powerful language allows for easier to write and
understand, and ergo higher quality, code long-term, with few or no
downsides.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 288 bytes --]

Re: Transitioning libgomp from C to C++ implementation

[Christopher Bazley]

Hi Arsen,

On 09/05/2026 10:08, Arsen Arsenović wrote:
> 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.

You could do something like this in C2Y (although it would be more 
straightforward and transparent if the union weren't discriminated):

// https://godbolt.org/z/41xsoWh1a
#include <stdio.h>

typedef struct {
     int dummy;
} tree;

typedef struct {
     tree node;
     int x, y, z;
} plus_expr;

typedef struct {
     tree node;
     double s, t, r;
} minus_expr;

typedef enum {
     TYPE_MINUS_EXPR,
     TYPE_PLUS_EXPR
} node_type;

typedef struct {
     node_type type__;
     union {
         plus_expr *plus;
         minus_expr *minus;
     } u__;
} unary_expr;

#define TO_UNARY_EXPR(E) \
   _Generic(E, \
            plus_expr *: \
             (unary_expr){TYPE_PLUS_EXPR, .u__.plus = (void *)(E)}, \
            minus_expr *: \
             (unary_expr){TYPE_MINUS_EXPR, .u__.minus = (void *)(E)})

#define UNARY_EXPR_TO_PLUS(E) \
   ((E).type__ == TYPE_PLUS_EXPR ? (E).u__.plus : nullptr)

#define UNARY_EXPR_TO_MINUS(E) \
   ((E).type__ == TYPE_MINUS_EXPR ? (E).u__.minus : nullptr)

void foo(unary_expr e)
{
     if (auto p = UNARY_EXPR_TO_PLUS(e))
     {
         printf("%d", p->x);
     }
     else if (auto p = UNARY_EXPR_TO_MINUS(e))
     {
         printf("%g", p->s);
     }
}

void bar(void)
{
     auto plus = &(plus_expr){};
     foo(TO_UNARY_EXPR(plus));

     auto minus = &(minus_expr){};
     foo(TO_UNARY_EXPR(minus));
}

However, I cannot recall any errors in my C programs caused by misuse of 
a discriminated union or a subtype accessed via CONTAINER_OF. Any 
problem worth solving is usually more interesting than that.

-- 
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/

Re: Transitioning libgomp from C to C++ implementation

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Sat, 9 May 2026, 09:40 Christopher Bazley via Gcc, <gcc@gcc.gnu.org>
wrote:

>
>
> This flaw in the design of C++ is also what necessitated the invention
> of nullptr, which would otherwise be unnecessary. Had the purpose of
> 'void *' not been misunderstood, nullptr could simply have been defined
> as a macro: ((void *)0).


No it couldn't.

This thread is getting more and more of topic, but defining nullptr as just
a void* would not allow the useful property of overloading functions like
unique_ptr::operator= on whether the argument is an actual pointer (which
would replace the owned pointer, but is disallowed by plain assignment) or
is the special nullptr value (which is allowed).

That is:

uptr = (void*)0; // error
uptr = nullptr; // ok

I think you have an overly simplistic idea of why nullptr was added to C++,
leading to an incorrect conclusion about it only being necessary because of
C++ pointer conversion rules.

It exists for reasons related to template type deduction and overloading,
not because void* isn't convertible to other pointer types.

Re: Transitioning libgomp from C to C++ implementation

[Eric Gallager]

On Thu, May 7, 2026 at 7:18 AM Thomas Schwinge <tschwinge@baylibre.com> 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.

Re: Transitioning libgomp from C to C++ implementation

[Martin Uecker]

Am Samstag, dem 09.05.2026 um 14:21 +0100 schrieb Jonathan Wakely via Gcc:
> On Sat, 9 May 2026, 09:40 Christopher Bazley via Gcc, <gcc@gcc.gnu.org>
> wrote:
> 
> > 
> > 
> > This flaw in the design of C++ is also what necessitated the invention
> > of nullptr, which would otherwise be unnecessary. Had the purpose of
> > 'void *' not been misunderstood, nullptr could simply have been defined
> > as a macro: ((void *)0).
> 
> 
> No it couldn't.
> 
> This thread is getting more and more of topic, but defining nullptr as just
> a void* would not allow the useful property of overloading functions like
> unique_ptr::operator= on whether the argument is an actual pointer (which
> would replace the owned pointer, but is disallowed by plain assignment) or
> is the special nullptr value (which is allowed).
> 
> That is:
> 
> uptr = (void*)0; // error
> uptr = nullptr; // ok
> 
> I think you have an overly simplistic idea of why nullptr was added to C++,
> leading to an incorrect conclusion about it only being necessary because of
> C++ pointer conversion rules.
> 
> It exists for reasons related to template type deduction and overloading,
> not because void* isn't convertible to other pointer types.

This was indeed the reason given in the original paper why (void*)0 was
not used.  The other use cases make sense though.

Martin

Re: Transitioning libgomp from C to C++ implementation

[Christopher Bazley]

On 09/05/2026 14:21, Jonathan Wakely wrote:
> 
> 
> On Sat, 9 May 2026, 09:40 Christopher Bazley via Gcc, <gcc@gcc.gnu.org 
> <mailto:gcc@gcc.gnu.org>> wrote:
> 
> 
> 
>     This flaw in the design of C++ is also what necessitated the invention
>     of nullptr, which would otherwise be unnecessary. Had the purpose of
>     'void *' not been misunderstood, nullptr could simply have been defined
>     as a macro: ((void *)0).
> 
> 
> No it couldn't.

Yes, my words misrepresented the order of events.

It is surprising to me that nullptr wasn't invented until C++11, given 
that there were known issues with overloading since the inception of C 
with classes. Those early problems with overloading do appear to stem 
from Stroustrup's redefinition of the semantics of the 'void *' type. I 
stand by that.

The idea of using '0' as a null pointer constant seems so bad to me that 
I can scarcely believe it was standard C++ for so long. That is what led 
to my wrong statement.

> This thread is getting more and more of topic, but defining nullptr as 
> just a void* would not allow the useful property of overloading 
> functions like unique_ptr::operator= on whether the argument is an 
> actual pointer (which would replace the owned pointer, but is disallowed 
> by plain assignment) or is the special nullptr value (which is allowed).
> 
> That is:
> 
> uptr = (void*)0; // error
> uptr = nullptr; // ok

Thanks for the explanation.

I can see that nullptr has some use for template type deduction, 
although based on your description I find that usage questionable. 
Assignments do not generally have different semantics depending on 
whether the assigned expression is a literal or not.

> I think you have an overly simplistic idea of why nullptr was added to 
> C++, leading to an incorrect conclusion about it only being necessary 
> because of C++ pointer conversion rules.

My "overly simplistic idea" was derived from my reading of Stroustrup 
(1994, reprinted 1998), 'The Design and Evolution of C++' (pp 230):

================
A void* cannot be assigned to anything without a cast.  Allowing 
implicit conversions of void* to other pointer types would open a 
serious hole in the type sustem.  One might make a special case for 
(void*)0, but special cases should only be admitted in dire need.  Also, 
C++ usage was determined long before there was an ANSI C standard, and I 
do not want to have any critical part of C++ rely on a macro. 
Consequently, I used plain 0, and that has worked very well over the 
years.  People who insist on a symbolic constant usually defined one of

const int NULL = 0; // or
#define NULL 0

As far as the compiler is concerned, NULL and 0 are then synonymous. 
Unfortunately, so many people have added definitions NULL, NIL, Null, 
null, etc. to their code that providing yet another definition can be 
hazardous.

There is one kind of mistake that is not caught when 0 (however spelled) 
is used for the null pointer.  Consider:

void f(char*);

void g() { f(0); } // calls f(char*)

Now add another f() and the meaning of g() silently changes:

void f(char*);
void f(int);

void g() { f(0); } // calls f(int)

This is an unfortunately side effect of 0 being an int that can be 
promoted to the null pointer, rather than a direct specification of the 
null pointer.  I think a good compiler should warn, but I didn't think 
of that in time for CFront.  Making the call to f(0) ambiguous rather 
than resolving it in favour of f(int) would be feasible, but would 
probably not satisfy the people would want NULL or nil to be magical.
================

What I remembered was Stroustrup's explanation (which I don't find 
particularly compelling) of why C++ did not use (void*)0 as a null 
pointer constant. However, I forgot that his book can't be used directly 
to justify the invention of nullptr, because nullptr hadn't been 
invented when he wrote the book.

> It exists for reasons related to template type deduction and 
> overloading, not because void* isn't convertible to other pointer types.

I don't think nullptr is necessary to resolve the problem with 
overloading that Stroustrup mentioned in his book. Consider his example, 
assuming that NULL is defined as ((void *)0) and assuming that C++ had 
not departed from C's semantics for void *:

void f(char*);

void g() { f(NULL); } // calls f(char*)

But also:

void f(char*);
void f(int);

void g() { f(NULL); } // still calls f(char*)

-- 
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/

Transitioning libgomp from C to C++ implementation: RTEMS

[Thomas Schwinge]

Hi GCC/RTEMS maintainers!

On 2026-05-07T13:16:59+0200, I wrote:
> [...]
>
> The idea of transitioning libgomp from C to C++ implementation has come
> up a number of times, [...]
>
> 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.
>
> [...]

Per my understanding, for GCC/RTEMS, libgomp is not enabled by default in
GCC 'configure.ac' (needs explicit '--enable-libgomp'), but it appears to
be supported: RTEMS is mentioned in 'libgomp/configure.ac',
'libgomp/configure.tgt', and has 'libgomp/config/rtems/' files.  Please
let me know in case libgomp/RTEMS is in fact not supported (anymore).

Assuming it is supported, I shall try to not break it.

During ongoing development, I'll need to run a number of GCC/libgomp
builds for RTEMS over the next few weeks/months (tentatively); therefore
would like to do it myself instead of asking you each time.

I need GCC 'configure'd with '--enable-languages=c,c++,fortran',
'--enable-libgomp', and then 'make', and 'make check-target-libgomp' if
feasible.

Ideally, easiest, I'd do native builds, but that may not be applicable
for RTEMS?  I don't see any RTEMS systems listed on
<https://portal.cfarm.net/machines/list/>.  Otherwise, cross builds with
testing option, or without testing, in case that's not feasible.  (I
assume that, as for other configurations, also for RTEMS my C -> C++
baseline conversion changes are good to go, once they compile without
error.)

Per 'libgomp/configure.ac':

    *-*-rtems*)
      AC_CHECK_TYPES([struct _Mutex_Control],[],[],[#include <sys/lock.h>])

..., and 'libgomp/configure.tgt':

    *-*-rtems*)
          # Use self-contained synchronization objects if provided by Newlib
          if test "x$ac_cv_type_struct__Mutex_Control" = xyes ; then
              config_path="rtems posix"

..., there appear to be two major configuration variants: either only
'libgomp/config/posix/', or 'libgomp/config/rtems/' plus the former.  (As
far as I can easily tell, there aren't any compile-time conditionals in
the 'libgomp/config/rtems/' files, so I assume I don't really care about
the specific CPU architecture.)


Grüße
 Thomas

Re: Transitioning libgomp from C to C++ implementation: RTEMS

[Sebastian Huber]

Dear Thomas,

----- Am 21. Jun 2026 um 9:06 schrieb Thomas Schwinge tschwinge@baylibre.com:

> Hi GCC/RTEMS maintainers!
> 
> On 2026-05-07T13:16:59+0200, I wrote:
>> [...]
>>
>> The idea of transitioning libgomp from C to C++ implementation has come
>> up a number of times, [...]
>>
>> 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.
>>
>> [...]
> 
> Per my understanding, for GCC/RTEMS, libgomp is not enabled by default in
> GCC 'configure.ac' (needs explicit '--enable-libgomp'), but it appears to
> be supported: RTEMS is mentioned in 'libgomp/configure.ac',
> 'libgomp/configure.tgt', and has 'libgomp/config/rtems/' files.  Please
> let me know in case libgomp/RTEMS is in fact not supported (anymore).
> 
> Assuming it is supported, I shall try to not break it.

it is enabled for all RTEMS targets supporting SMP. This is aarch64, arm, riscv, powerpc, and sparc. It is actively used and there is an ongoing activity sponsored by the European Space Agency to enable the usage in critical systems. Moving from C to C++ will cause them some headaches, however, this should be of no concern for the GCC development.

> 
> During ongoing development, I'll need to run a number of GCC/libgomp
> builds for RTEMS over the next few weeks/months (tentatively); therefore
> would like to do it myself instead of asking you each time.
> 
> I need GCC 'configure'd with '--enable-languages=c,c++,fortran',
> '--enable-libgomp', and then 'make', and 'make check-target-libgomp' if
> feasible.
> 
> Ideally, easiest, I'd do native builds, but that may not be applicable
> for RTEMS?  I don't see any RTEMS systems listed on
> <https://portal.cfarm.net/machines/list/>.  Otherwise, cross builds with
> testing option, or without testing, in case that's not feasible.  (I
> assume that, as for other configurations, also for RTEMS my C -> C++
> baseline conversion changes are good to go, once they compile without
> error.)
> 
> Per 'libgomp/configure.ac':
> 
>    *-*-rtems*)
>      AC_CHECK_TYPES([struct _Mutex_Control],[],[],[#include <sys/lock.h>])
> 
> ..., and 'libgomp/configure.tgt':
> 
>    *-*-rtems*)
>          # Use self-contained synchronization objects if provided by Newlib
>          if test "x$ac_cv_type_struct__Mutex_Control" = xyes ; then
>              config_path="rtems posix"
> 
> ..., there appear to be two major configuration variants: either only
> 'libgomp/config/posix/', or 'libgomp/config/rtems/' plus the former.  (As
> far as I can easily tell, there aren't any compile-time conditionals in
> the 'libgomp/config/rtems/' files, so I assume I don't really care about
> the specific CPU architecture.)

This "if test "x$ac_cv_type_struct__Mutex_Control" = xyes ; then" is obsolete. The check is always true. I will remove this check.

You have to compile RTEMS with a cross-compiler. I can send you some build scripts to build the tools, RTEMS, a simulator, and an OpenMP test program.

Kind regards,
Sebastian

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: Transitioning libgomp from C to C++ implementation: RTEMS

[Thomas Schwinge]

[I note (again) that Joel Sherrill <joel@oarcorp.com> isn't deliverable
(CCing another address), and Ralf Corsepius <ralf.corsepius@rtems.org>
also isn't deliverable; please maintain GCC's 'MAINTAINERS' file.]


Hi Sebastian!

On 2026-06-22T05:11:30+0200, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:
> ----- Am 21. Jun 2026 um 9:06 schrieb Thomas Schwinge tschwinge@baylibre.com:
>> Hi GCC/RTEMS maintainers!
>> 
>> On 2026-05-07T13:16:59+0200, I wrote:
>>> [...]
>>>
>>> The idea of transitioning libgomp from C to C++ implementation has come
>>> up a number of times, [...]
>>>
>>> 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.
>>>
>>> [...]
>> 
>> Per my understanding, for GCC/RTEMS, libgomp is not enabled by default in
>> GCC 'configure.ac' (needs explicit '--enable-libgomp'), but it appears to
>> be supported: RTEMS is mentioned in 'libgomp/configure.ac',
>> 'libgomp/configure.tgt', and has 'libgomp/config/rtems/' files.  Please
>> let me know in case libgomp/RTEMS is in fact not supported (anymore).
>> 
>> Assuming it is supported, I shall try to not break it.
>
> it is enabled for all RTEMS targets supporting SMP. This is aarch64, arm, riscv, powerpc, and sparc. It is actively used

That's great to hear!

> and there is an ongoing activity sponsored by the European Space Agency to enable the usage in critical systems.

Interesting!  If there are any concerns -- or publications -- regarding
use of libgomp in critical systems, we'd be interested to hear.
(Different topic, different email thread.)

> Moving from C to C++ will cause them some headaches, however, this should be of no concern for the GCC development.

This is purely about the implementation of libgomp itself, internally.
All external interfaces (ABI) remain compatible/unchanged, and also the
compiled libgomp object code should mostly be the same as the current C
implementation.  Any specific concerns that we should work on addressing?

>> During ongoing development, I'll need to run a number of GCC/libgomp
>> builds for RTEMS over the next few weeks/months (tentatively); therefore
>> would like to do it myself instead of asking you each time.
>> 
>> I need GCC 'configure'd with '--enable-languages=c,c++,fortran',
>> '--enable-libgomp', and then 'make', and 'make check-target-libgomp' if
>> feasible.
>> 
>> Ideally, easiest, I'd do native builds, but that may not be applicable
>> for RTEMS?  I don't see any RTEMS systems listed on
>> <https://portal.cfarm.net/machines/list/>.  Otherwise, cross builds with
>> testing option, or without testing, in case that's not feasible.  (I
>> assume that, as for other configurations, also for RTEMS my C -> C++
>> baseline conversion changes are good to go, once they compile without
>> error.)
>> 
>> Per 'libgomp/configure.ac':
>> 
>>    *-*-rtems*)
>>      AC_CHECK_TYPES([struct _Mutex_Control],[],[],[#include <sys/lock.h>])
>> 
>> ..., and 'libgomp/configure.tgt':
>> 
>>    *-*-rtems*)
>>          # Use self-contained synchronization objects if provided by Newlib
>>          if test "x$ac_cv_type_struct__Mutex_Control" = xyes ; then
>>              config_path="rtems posix"
>> 
>> ..., there appear to be two major configuration variants: either only
>> 'libgomp/config/posix/', or 'libgomp/config/rtems/' plus the former.  (As
>> far as I can easily tell, there aren't any compile-time conditionals in
>> the 'libgomp/config/rtems/' files, so I assume I don't really care about
>> the specific CPU architecture.)
>
> This "if test "x$ac_cv_type_struct__Mutex_Control" = xyes ; then" is obsolete. The check is always true. I will remove this check.

Thanks, that's good to know.

> You have to compile RTEMS with a cross-compiler. I can send you some build scripts to build the tools, RTEMS, a simulator, and an OpenMP test program.

OK, that sounds about what I expected.  Please send the build scripts
that you have, thanks!


Grüße
 Thomas

Transitioning libgomp from C to C++ implementation: Darwin

[Thomas Schwinge]

Hi GCC/Darwin maintainers (Iain, Mike), cfarm104 administrator (Zach)!

Short version: once cfarm104 is back online
(<https://lists.tetaneutral.net/pipermail/cfarm-users/2026-June/001637.html>
"cfarm104 updates and likely downtime"), can I assume that something to
the effect of:

    $ [GCC]/configure --enable-languages=c,c++,fortran
    $ make
    $ make check-target-libgomp

... just works on cfarm104?  <https://portal.cfarm.net/machines/list/>
lists it as a "Mac mini (2020), arm64 Apple M1, MacOSX" system; the only
"Darwin" system that we've got available for public access?

In more detail:

On 2026-05-07T13:16:59+0200, I wrote:
> [...]
>
> The idea of transitioning libgomp from C to C++ implementation has come
> up a number of times, [...]
>
> 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.
>
> [...]

Per my understanding, for GCC/Darwin, libgomp is enabled by default in
GCC 'configure.ac', and I see Darwin mentioned in 'libgomp/configure.ac',
'libgomp/configure.tgt', and there are 'libgomp/config/darwin/' files.
Please let me know if libgomp/Darwin is in fact not supported (anymore).

Assuming it is supported, I shall try to not break it.

During ongoing development, I'll need to run a number of GCC/libgomp
builds for Darwin over the next few weeks/months (tentatively); therefore
would like to do it myself instead of asking you each time.

As I said above, I need GCC 'configure'd with
'--enable-languages=c,c++,fortran', '--enable-libgomp' (should be
default), and then 'make', and 'make check-target-libgomp' if feasible.

Ideally, easiest, I'd do native builds.  Otherwise, cross builds with
testing option, or without testing, in case that's not feasible.  (I
assume that, as for other configurations, my C -> C++ baseline conversion
changes are good to go also for Darwin, once they compile without error.)

In particular, I'd like to test the following libgomp configuration
variants, which are specific to Darwin:

Per 'libgomp/configure.ac':

    # Check for broken semaphore implementation on darwin.
    # sem_init returns: sem_init error: Function not implemented.
    case "$host" in
      *-darwin*)
        AC_DEFINE(HAVE_BROKEN_POSIX_SEMAPHORES, 1,
            Define if the POSIX Semaphores do not work on your system.)
        ;;
    esac

..., that is, libgomp code conditional to 'HAVE_BROKEN_POSIX_SEMAPHORES'.

..., and 'libgomp/configure.tgt':

    *-*-darwin*)
          config_path="bsd darwin posix"

..., that is 'libgomp/config/bsd/', 'libgomp/config/darwin/' files.  (Not
too much in there, but still...)

As far as I can easily tell, there aren't any architecture-specific
compile-time conditionals in these files, so I assume I don't really care
about the specific CPU architecture.

('libgomp/config/posix/' files are also execised by other configurations,
unsurprisingly.)


Grüße
 Thomas

Re: Transitioning libgomp from C to C++ implementation: Darwin

[Iain Sandoe]

Hi Thomas,

libgomp is supported on darwin,

> On 2 Jul 2026, at 22:57, Thomas Schwinge <tschwinge@baylibre.com> wrote:
> 
> Hi GCC/Darwin maintainers (Iain, Mike), cfarm104 administrator (Zach)!
> 
> Short version: once cfarm104 is back online
> (<https://lists.tetaneutral.net/pipermail/cfarm-users/2026-June/001637.html>
> "cfarm104 updates and likely downtime"), can I assume that something to
> the effect of:
> 
>    $ [GCC]/configure --enable-languages=c,c++,fortran
>    $ make
>    $ make check-target-libgomp
> 
> ... just works on cfarm104?  <https://portal.cfarm.net/machines/list/>
> lists it as a "Mac mini (2020), arm64 Apple M1, MacOSX" system; the only
> "Darwin" system that we've got available for public access?

No, not quite, since the aarch64 port is not yet upstreamed (which is needed
for the Mx chips).

However, if that host has ROSETTA2 installed, it is possible to build 
x86_64-apple-darwinNN (NN depending on what OS version is installed).

If you decide to do that, I can provide a short set of instructions to avoid hassles.

====

Failing that, you can checkout the aarch64 development branch:

https://github.com/iains/gcc-darwin-arm64

which is usually within a few days of tip-of-trunk.

====

In either case : 

 * Since darwin no longer supports installing headers and library stubs into /
you also need to provide a sysroot to the configure:

—with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

should work if the command line tools are installed, which I believe they are
if the machine has a homebrew install (it did last time I looked).

 * you should configure for a specific darwin version
  —build=<arch>-apple-darwinNN 
 (since darwin GCC supports multiple OS versions)

I don’t know if that machine has an installation of GCC that would be suitable for 
bootstrap - but clang should work fine (unless you want to build Ada or D).

I recommend appending CC=clang  CXX=clang++ to the configure (since xcode
clang claims to be gcc but does not support modern gcc, it is safer to be explicit)

======= 

from the detailed section….

> Per 'libgomp/configure.ac':
> 
>    # Check for broken semaphore implementation on darwin.
>    # sem_init returns: sem_init error: Function not implemented.
>    case "$host" in
>      *-darwin*)
>        AC_DEFINE(HAVE_BROKEN_POSIX_SEMAPHORES, 1,
>            Define if the POSIX Semaphores do not work on your system.)
>        ;;

I think one might want to check that this is really still true - pthreads behaviour
has improved in recent years.

=====

barring the configure extras and needing to use lldb for debugging, the
behaviour of gcc on darwin should be quite familiar.

=====

If you just need a branch testing .. you can also ask me and I can cover a wider
range of OS versions.  If you need to do development, then obviously it’s better
to use the cfarm machine.

Iain

Transitioning libgomp from C to C++ implementation: Windows ('*-*-mingw32*')

[Thomas Schwinge]

Hi Jonathan!

The GCC 'MAINTAINERS' file lists you as maintainer for cygwin, mingw-w64.

On 2026-05-07T13:16:59+0200, I wrote:
> [...]
>
> The idea of transitioning libgomp from C to C++ implementation has come
> up a number of times, [...]
>
> 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.
>
> [...]

Per my understanding, for GCC/MinGW, libgomp is not enabled by default in
GCC 'configure.ac' (needs explicit '--enable-libgomp'), but it appears to
be supported: 'mingw32' (only explicitly '32', though?) is mentioned in
'libgomp/configure.tgt', and has 'libgomp/config/mingw32/' files.

What about the original MinGW vs. MinGW-w64 vs. Cygwin variants; does the
'*-*-mingw32*' triplet (as used in 'libgomp/configure.tgt') apply to all
these, or just some?

Please let me know in case libgomp/MinGW is in fact not supported
(anymore).

Assuming it is supported, I shall try to not break it.

During ongoing development, I'll need to run a number of GCC/libgomp
builds for the supported MinGW variants over the next few weeks/months
(tentatively); therefore would like to do it myself instead of asking you
each time.

I need GCC 'configure'd with '--enable-languages=c,c++,fortran',
'--enable-libgomp', and then 'make', and 'make check-target-libgomp' if
feasible.

Ideally, easiest, I'd do native builds.  Otherwise, cross builds with
testing option, or without testing, in case that's not feasible.  (I
assume that, as for other configurations, my C -> C++ baseline conversion
changes are good to go also for MinGW, once they compile without error.)

In particular, I'd like to test the following libgomp configuration
variants, which are specific to MinGW:

Per 'libgomp/configure.tgt':

    *-*-mingw32*)
          config_path="mingw32 posix"

..., that is 'libgomp/config/mingw32/' files.  As far as I can easily
tell, there aren't any architecture-specific compile-time conditionals in
these files, so I assume I don't really care about the specific CPU
architecture.

Additionally, MinGW-specific things in 'libgomp/config/posix/' and core
libgomp files.


I don't see any Windows systems listed on
<https://portal.cfarm.net/machines/list/>.  Are there any such systems
that I could log in remotely, and do my builds?

Otherwise, is cross-compiling GCC an option, and could you provide
pointers how to do that?


Grüße
 Thomas

Re: Transitioning libgomp from C to C++ implementation: Windows ('*-*-mingw32*')

[Jonathan Yong]

On 7/2/26 22:38, Thomas Schwinge wrote:
> Hi Jonathan!
> 
> The GCC 'MAINTAINERS' file lists you as maintainer for cygwin, mingw-w64.
> 

+LH, NS and Cygwin developers.

> On 2026-05-07T13:16:59+0200, I wrote:
>> [...]
>>
>> The idea of transitioning libgomp from C to C++ implementation has come
>> up a number of times, [...]
>>
>> 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.
>>
>> [...]
> 
> Per my understanding, for GCC/MinGW, libgomp is not enabled by default in
> GCC 'configure.ac' (needs explicit '--enable-libgomp'), but it appears to
> be supported: 'mingw32' (only explicitly '32', though?) is mentioned in
> 'libgomp/configure.tgt', and has 'libgomp/config/mingw32/' files.
> 
> What about the original MinGW vs. MinGW-w64 vs. Cygwin variants; does the
> '*-*-mingw32*' triplet (as used in 'libgomp/configure.tgt') apply to all
> these, or just some?
> 
> Please let me know in case libgomp/MinGW is in fact not supported
> (anymore).
> 

It should really be mingw* for consistency. *-*-mingw32* applies to both 
the original mingw and mingw-w64 while cygwin has its own triplet. 
mingw-w64 is identified by the w64 vendor part. As of now, libgomp 
depends on a pthread implementation being available, either the classic 
pthread-win32 or winpthreads or mcfgthread, which is not a default for 
mingw* target. Cygwin is a POSIX emulation layer on top of win32, so 
pthread is always available and libgomp should be enabled by default.

> Assuming it is supported, I shall try to not break it.
> 
> During ongoing development, I'll need to run a number of GCC/libgomp
> builds for the supported MinGW variants over the next few weeks/months
> (tentatively); therefore would like to do it myself instead of asking you
> each time.
> 
> I need GCC 'configure'd with '--enable-languages=c,c++,fortran',
> '--enable-libgomp', and then 'make', and 'make check-target-libgomp' if
> feasible.
> 
> Ideally, easiest, I'd do native builds.  Otherwise, cross builds with
> testing option, or without testing, in case that's not feasible.  (I
> assume that, as for other configurations, my C -> C++ baseline conversion
> changes are good to go also for MinGW, once they compile without error.)
> 
> In particular, I'd like to test the following libgomp configuration
> variants, which are specific to MinGW:
> 
> Per 'libgomp/configure.tgt':
> 
>      *-*-mingw32*)
>            config_path="mingw32 posix"
> 
> ..., that is 'libgomp/config/mingw32/' files.  As far as I can easily
> tell, there aren't any architecture-specific compile-time conditionals in
> these files, so I assume I don't really care about the specific CPU
> architecture.
> 

i686 and x86_64 mingw-w64 is most tested. There is also arm and aarch64 
mingw-w64 that is less tested.

> Additionally, MinGW-specific things in 'libgomp/config/posix/' and core
> libgomp files.
> 
> 
> I don't see any Windows systems listed on
> <https://portal.cfarm.net/machines/list/>.  Are there any such systems
> that I could log in remotely, and do my builds?
> 
> Otherwise, is cross-compiling GCC an option, and could you provide
> pointers how to do that?
> 

I don't know any available Windows machine for native testing, but 
cross-compilation should be the minimum. My own personal cross compiler 
configuration has --enable-host-shared --enable-fully-dynamic-string 
--enable-libstdcxx-threads --disable-multilib --enable-libgomp 
--enable-libssp, one build for each architecture. 
--enable-sjlj-exceptions is needed for i686 mingw* while no specific 
exception argument is set for x86_64 so SEH exception is used. multilib 
is also a supported but setup is more complicated.

Cygwin configuration details is available at 
https://www.cygwin.com/cgit/cygwin-packages/gcc/tree/gcc.cygport, only 
x86_64 cygwin is supported currently, i686 is no longer maintained.

There is a known race condition when enabling libgomp and C++ at the 
same time where libgomp depends on target/bits headers from libstdc++ 
being generated while libstdc++.la depends on libgomp.la being 
generated. It might be a mingw* specific issue, one that I'm not sure 
how to resolve.

Re: Transitioning libgomp from C to C++ implementation: Windows ('*-*-mingw32*')

[LIU Hao]

[-- Attachment #1.1: Type: text/plain, Size: 5053 bytes --]

在 2026-7-3 08:53, Jonathan Yong 写道:

> It should really be mingw* for consistency. *-*-mingw32* applies to both the original mingw and mingw-w64 
> while cygwin has its own triplet. mingw-w64 is identified by the w64 vendor part. As of now, libgomp 
> depends on a pthread implementation being available, either the classic pthread-win32 or winpthreads or 
> mcfgthread, which is not a default for mingw* target. Cygwin is a POSIX emulation layer on top of win32, 
> so pthread is always available and libgomp should be enabled by default.

At the moment, libgomp calls pthread functions such as `pthread_attr_setstacksize()` and 
`pthread_create()` even when `LIBGOMP_USE_PTHREADS` is not defined, so it's not buildable without 
winpthreads.


There are some missing parts in existing mingw32/ which I have sent to gcc-patches:

    * 
https://github.com/lhmouse/MINGW-packages/blob/ad0a520b84efe92975a1ee80fe81cd530da435a0/mingw-w64-gcc/9202-libgomp-mingw32-Increase-precision-of-omp_get_wtime-.patch
    * 
https://github.com/lhmouse/MINGW-packages/blob/ad0a520b84efe92975a1ee80fe81cd530da435a0/mingw-w64-gcc/9203-libgomp-mingw32-Fix-plugin-suffix.patch
    * 
https://github.com/lhmouse/MINGW-packages/blob/ad0a520b84efe92975a1ee80fe81cd530da435a0/mingw-w64-gcc/9204-libgomp-mingw32-Implement-cpu_relax-and-doacross_spi.patch


Coincidentally, in this week I have managed to build libgomp without winpthreads with this patch:

    * 
https://github.com/lhmouse/MINGW-packages/blob/ad0a520b84efe92975a1ee80fe81cd530da435a0/mingw-w64-gcc/9205-libgomp-win32-Add-win32-implementation.patch


This allows building libgomp with win32 or mcf thread model. When yesterday I tried to build GCC master 
it ICE'd, so I had to backport the patches to GCC 16, and everything built successfully.

However, it turns out that any program that is linked against libgomp DLL deadlocks upon exit; the reason 
is complex but tl;dr; mingw-w64 CRT has to be patched as well (which I'll push later today):

    * https://sourceforge.net/p/mingw-w64/mailman/message/59353887/


> 
>> Assuming it is supported, I shall try to not break it.
>>
>> During ongoing development, I'll need to run a number of GCC/libgomp
>> builds for the supported MinGW variants over the next few weeks/months
>> (tentatively); therefore would like to do it myself instead of asking you
>> each time.
>>
>> I need GCC 'configure'd with '--enable-languages=c,c++,fortran',
>> '--enable-libgomp', and then 'make', and 'make check-target-libgomp' if
>> feasible.
>>
>> Ideally, easiest, I'd do native builds.  Otherwise, cross builds with
>> testing option, or without testing, in case that's not feasible.  (I
>> assume that, as for other configurations, my C -> C++ baseline conversion
>> changes are good to go also for MinGW, once they compile without error.)
>>
>> In particular, I'd like to test the following libgomp configuration
>> variants, which are specific to MinGW:
>>
>> Per 'libgomp/configure.tgt':
>>
>>      *-*-mingw32*)
>>            config_path="mingw32 posix"
>>
>> ..., that is 'libgomp/config/mingw32/' files.  As far as I can easily
>> tell, there aren't any architecture-specific compile-time conditionals in
>> these files, so I assume I don't really care about the specific CPU
>> architecture.
>>
> 
> i686 and x86_64 mingw-w64 is most tested. There is also arm and aarch64 mingw-w64 that is less tested.

There's no architecture-specific hack. (In my patch 9204 above, it's covered by `YieldProcessor()` which 
is defined in winnt.h, thankfully.)


>> Additionally, MinGW-specific things in 'libgomp/config/posix/' and core
>> libgomp files.
>>
>>
>> I don't see any Windows systems listed on
>> <https://portal.cfarm.net/machines/list/>.  Are there any such systems
>> that I could log in remotely, and do my builds?
>>
>> Otherwise, is cross-compiling GCC an option, and could you provide
>> pointers how to do that?
>>
> 
> I don't know any available Windows machine for native testing, but cross-compilation should be the 
> minimum. My own personal cross compiler configuration has --enable-host-shared --enable-fully-dynamic- 
> string --enable-libstdcxx-threads --disable-multilib --enable-libgomp --enable-libssp, one build for each 
> architecture. --enable-sjlj-exceptions is needed for i686 mingw* while no specific exception argument is 
> set for x86_64 so SEH exception is used. multilib is also a supported but setup is more complicated.

I do native x86-64 builds almost all the time. If you don't have a native Windows machine, I suggest you 
have a look at GitHub Actions which provides Windows runners on x86-64 and ARM64. It's where we 
(mingw-w64) run our CI, and also where MSYS2 build their packages.

This is the MSYS2 recipe to build their native compilers:

    * 
https://github.com/msys2/MINGW-packages/blob/100faa15d7ed50930f8a82a84f98abef5a76862d/mingw-w64-gcc/PKGBUILD#L140-L307


-- 
Best regards,
LIU Hao

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Transitioning libgomp from C to C++ implementation: Windows ('*-*-mingw32*')

[LIU Hao]

[-- Attachment #1.1: Type: text/plain, Size: 1235 bytes --]

在 2026-7-3 10:45, LIU Hao via Gcc 写道:
> This allows building libgomp with win32 or mcf thread model. When yesterday I tried to build GCC master 
> it ICE'd, so I had to backport the patches to GCC 16, and everything built successfully.
> 
> However, it turns out that any program that is linked against libgomp DLL deadlocks upon exit; the reason 
> is complex but tl;dr; mingw-w64 CRT has to be patched as well (which I'll push later today):

With https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0fad182ff178044ee442b05e1913aa16cde8efcf/ 
committed, I tried updating mingw-w64 CRT and rebuilding GCC with win32 thread model.

The ICE was gone, so I went ahead and ran libgomp tests. There were ~20 failures in C and C++ tests; some 
of them didn't compile, for example, libgomp/testsuite/libgomp.c-c++-common/cancel-taskgroup-1.c contains 
a call to `random()` which doesn't exist on Windows, and libgomp/alloc_cache.h still contains calls to 
pthread functions. There were also many failures in Fortran tests which I'm not familiar with.

I think this attempt to port libgomp to Windows without winpthreads is almost complete, but there are 
still some remaining changes.




-- 
Best regards,
LIU Hao

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]