[Comgr][test] Add -nostdinc++ to compile_hip_with_libcxx_test#2444
Open
lamb-j wants to merge 3 commits into
Open
[Comgr][test] Add -nostdinc++ to compile_hip_with_libcxx_test#2444lamb-j wants to merge 3 commits into
lamb-j wants to merge 3 commits into
Conversation
Collaborator
Collaborator
lamb-j
added a commit
that referenced
this pull request
May 7, 2026
## Summary Disable `compile_hip_with_libcxx_test` -- it currently fails on systems with system libstdc++ at clang's default search path (manylinux/RHEL with gcc-toolset). Root cause and proper fix tracked in #2444 and #2445; will be re-enabled by #2444 once that lands. Co-authored-by: Claude <noreply@anthropic.com>
The test claims to verify that embedded libc++ headers work with HIP
compilation, but only passes -nogpuinc -- which disables GPU-specific
includes but leaves system C++ header lookup enabled.
On systems with system libstdc++ installed at clang's default search
path (manylinux/RHEL with gcc-toolset), clang resolves <tuple> to the
system header, which transitively pulls in <stddef.h> from
cxxabi_init_exception.h. That stddef.h resolves to clang's libc++
stddef.h, which does #include_next <stddef.h>. Under HIP
--offload-device-only mode there is no next stddef.h on the device
include path, so the chain breaks:
In file included from .../cxxabi_init_exception.h:38:
include/c++/v1/stddef.h:39:15: fatal error: 'stddef.h' file not found
39 | #include_next <stddef.h>
This is a real coverage gap in the test (it isn't actually verifying
the embedded headers in environments that have system libstdc++) and a
silent failure mode of the underlying COMPILE_SOURCE_WITH_DEVICE_LIBS_TO_BC
action (the embedded-fallback design at comgr-compiler.cpp:1211-1216
assumes any present system libstdc++ works on its own; under HIP device
mode that assumption is broken on RHEL/manylinux).
Add -nostdinc++ to the test so it actually isolates the embedded
headers, which is what the test name and comments claim.
A separate issue tracks the broader design question of whether comgr
should auto-inject -nostdinc++ with -nogpuinc, or promote the embedded
libc++ from -idirafter to -isystem.
Co-Authored-By: Claude <noreply@anthropic.com>
The full root-cause chain lives in issue #2445; the test only needs to explain why -nostdinc++ is here. Co-Authored-By: Claude <noreply@anthropic.com>
Reverts the disable from #2447 now that the underlying issue (the test not passing -nostdinc++) is fixed by this PR. Co-Authored-By: Claude <noreply@anthropic.com>
e98d745 to
f400351
Compare
Collaborator
chinmaydd
approved these changes
May 7, 2026
Collaborator
Author
|
!PSDB |
Collaborator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
compile_hip_with_libcxx_testclaims to verify that embedded libc++ headers work with HIP compilation, but only passes-nogpuinc-- which disables GPU-specific includes but leaves system C++ header lookup enabled. On systems with system libstdc++ installed at clang's default search path (manylinux / RHEL with gcc-toolset), the test silently exercises system libstdc++, not the embedded headers.Worse, on RHEL/manylinux specifically, the test fails at
amd_comgr_do_action():Root cause
#include <tuple>.<tuple>to system gcc-8 libstdc++ (/usr/lib/gcc/.../include/c++/8/tuple) because the embedded libc++ is injected at-idirafterpriority (comgr-compiler.cpp:1211-1216).<exception_ptr.h>-><cxxabi_init_exception.h>-><stddef.h>.stddef.hresolves to libc++'sinclude/c++/v1/stddef.h(VFS-mapped to clang's resource dir).#include_next <stddef.h>-- but under HIP--offload-device-onlywith-nogpuinc, no further stddef.h is available on the device include path. Chain breaks.Fix
Add
-nostdinc++to the test's compile options so clang only finds the embedded headers, which is what the test name and comments claim to verify. Tested in the manylinux container -- test now passes.This was caught by the new SPIRV CI workflow on
ROCm/SPIRV-LLVM-TranslatorPR #178, which builds Comgr inside the manylinux container that other compiler-stack workflows use.Follow-up
Filed a separate issue tracking the broader design question (whether comgr should auto-inject
-nostdinc++with-nogpuinc, or promote the embedded libc++ from-idirafterto-isystemso users don't have to opt in explicitly).