Skip to content

build: Update C++ standard from c++17 to c++20 - #128

Merged
mc-nv merged 3 commits into
mainfrom
mchornyi/TRI-1877/TRI-1855-std-20
Sep 11, 2026
Merged

mc-nv merged 3 commits into
mainfrom
mchornyi/TRI-1877/TRI-1855-std-20

Conversation

@mc-nv

@mc-nv mc-nv commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

What does the PR do?

Checklist

  • PR title reflects the change and is of format <commit_type>: <Title>
  • Changes are described in the pull request.
  • Related issues are referenced.
  • Populated github labels field
  • Added test plan and verified test passes.
  • Verified that the PR passes existing CI.
  • Verified copyright is correct on all changed files.
  • Added succinct git squash message before merging ref.
  • All template sections are filled out.
  • Optional: Additional screenshots for behavior/output changes with before/after.

Commit Type:

Check the conventional commit type box here and add the label to the github PR.

  • build
  • ci
  • docs
  • feat
  • fix
  • perf
  • refactor
  • revert
  • style
  • test

Related PRs:

Where should the reviewer start?

  • CMakeLists.txt

Test plan:

  • CI Pipeline ID: 67062220

Caveats:

This repo has no direct dependency on ATen/libtorch; the bump is for cross-repo C++ standard consistency, not a confirmed build break here.

Background

Part of a coordinated C++17->C++20 bump across ~18 Triton component repos (TRI-1877), triggered by upstream PyTorch's ATen.h now requiring C++20.

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

  • Resolves: TRI-1877

Upstream PyTorch raised ATen's minimum required C++ standard from 17
to 20 (pytorch/pytorch#178150), which broke the pytorch_backend build.
Align this repo's TRITON_MIN_CXX_STANDARD/CMAKE_CXX_STANDARD default
with that floor for consistency across the stack.

TRI-1877
@mc-nv mc-nv self-assigned this Sep 9, 2026
@mc-nv mc-nv added the build Build system or external dependencies (build: PRs) label Sep 9, 2026
This was referenced Sep 9, 2026
Under C++20, libstdc++'s <condition_variable> transitively needs the
POSIX <semaphore.h> to support std::counting_semaphore. This repo's
own src/semaphore.h has the same name and sits ahead of the system
include path (-I<src> precedes default system dirs), so the compiler
resolved the internal #include <semaphore.h> to this project's own
header instead of glibc's, which defines no POSIX semaphore symbols.
That broke the C++17->20 bump build with a cascade of "sem_t does not
name a type" / "condition_variable does not name a type" errors.

Rename to triton_semaphore.h so it can no longer shadow the system
header; harmless under C++17 since nothing pulled in <semaphore.h>
there.

TRI-1877
Same class of bug as the semaphore.h rename in this repo: a project
header sharing a name with a C++ standard library header, combined
with -I<src> preceding the system include path, means any future
internal #include <filesystem> from libstdc++ (or a toolchain bump)
would silently resolve to this project's own header instead. Not
currently triggering a build failure, but proactively renamed given
this repo already proved the pattern is live once.

TRI-1877
@mc-nv mc-nv added the fix Bug fix (fix: PRs) label Sep 9, 2026
@mc-nv
mc-nv marked this pull request as ready for review September 10, 2026 15:28
@greptile-apps

greptile-apps Bot commented Sep 10, 2026

Copy link
Copy Markdown

RetriggerConfidence Score: 5/5

The PR appears safe to merge, with the C++20 setting and associated collision-avoidance renames applied consistently.

Summary

  • Applies cxx_std_20 to the backend target through the existing configurable CMake variable.
  • Updates all internal includes and build-source entries for the renamed files.
  • Preserves the existing filesystem, shared-library, and execution-synchronization behavior.

Reviews (1) · Last reviewed commit: "fix: rename filesystem.h/.cc to avoid co..."

@mc-nv
mc-nv requested a review from mattwittwer September 10, 2026 18:21

@mattwittwer mattwittwer left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mc-nv
mc-nv merged commit 38b69d0 into main Sep 11, 2026
2 checks passed
@mc-nv
mc-nv deleted the mchornyi/TRI-1877/TRI-1855-std-20 branch September 11, 2026 03:15
mc-nv added a commit that referenced this pull request Sep 11, 2026
* build: Update C++ standard from c++17 to c++20

Upstream PyTorch raised ATen's minimum required C++ standard from 17
to 20 (pytorch/pytorch#178150), which broke the pytorch_backend build.
Align this repo's TRITON_MIN_CXX_STANDARD/CMAKE_CXX_STANDARD default
with that floor for consistency across the stack.

TRI-1877

* fix: rename semaphore.h to avoid colliding with POSIX <semaphore.h>

Under C++20, libstdc++'s <condition_variable> transitively needs the
POSIX <semaphore.h> to support std::counting_semaphore. This repo's
own src/semaphore.h has the same name and sits ahead of the system
include path (-I<src> precedes default system dirs), so the compiler
resolved the internal #include <semaphore.h> to this project's own
header instead of glibc's, which defines no POSIX semaphore symbols.
That broke the C++17->20 bump build with a cascade of "sem_t does not
name a type" / "condition_variable does not name a type" errors.

Rename to triton_semaphore.h so it can no longer shadow the system
header; harmless under C++17 since nothing pulled in <semaphore.h>
there.

TRI-1877

* fix: rename filesystem.h/.cc to avoid colliding with <filesystem>

Same class of bug as the semaphore.h rename in this repo: a project
header sharing a name with a C++ standard library header, combined
with -I<src> preceding the system include path, means any future
internal #include <filesystem> from libstdc++ (or a toolchain bump)
would silently resolve to this project's own header instead. Not
currently triggering a build failure, but proactively renamed given
this repo already proved the pattern is live once.

TRI-1877

(cherry picked from commit 38b69d0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Build system or external dependencies (build: PRs) fix Bug fix (fix: PRs)

Development

Successfully merging this pull request may close these issues.

2 participants