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

Project / Subsystem

gcc / gcc

Date

2026-07-07

Proposer

LIU Hao <lh_mouse@126.com>

Source type

public_inbox

Consensus

Proposed

Sentiment

/10

Technical tradeoffs

  • Switching libgomp to C++ might offer better abstraction but introduces C++/Windows integration challenges.
  • Avoiding winpthreads for mingw-w64 targets simplifies dependencies but requires careful handling of Windows-native threading primitives.

All attributes

project
gcc
subsystem
gcc
patch_id
discussion_id
d9817db4-4d9b-4b71-ba43-0e9d98fba873@126.com
source_type
public_inbox
title
Re: Transitioning libgomp from C to C++ implementation: Windows ('*-*-mingw32*')
headline
Transitioning libgomp for Windows fails with ICE and deadlocks
tldr
Porting libgomp to Windows using mingw-w64 without winpthreads leads to ICEs and deadlocks, with remaining test failures.
proposer
LIU Hao <lh_mouse@126.com>
consensus
Proposed
outcome
needs_revision
sentiment_score
technical_tradeoffs
  • Switching libgomp to C++ might offer better abstraction but introduces C++/Windows integration challenges.
  • Avoiding winpthreads for mingw-w64 targets simplifies dependencies but requires careful handling of Windows-native threading primitives.
series_id
series_role
standalone
series_parts
[]
tags
  • windows
  • mingw
  • libgomp
  • threading
  • runtime
bugzilla_url
date
2026-07-07T00:00:00.000Z

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

Following a successful backport of libgomp C++ transition patches to GCC 16, issues arose on Windows where linking against the libgomp DLL caused deadlocks. Despite patching mingw-w64 CRT and attempting a rebuild with the win32 thread model, an ICE was resolved but test failures persist, including missing functions and use of pthread equivalents.