Change VOLATILE_MEMORY_BARRIER for x64 Unix - #131807
Merged
Merged
Conversation
Currently the macro is defined as asm volatile ("" : : : "memory"). That
caused a recent regression in HndWriteBarrier due to an added
VolatileStore where clang adds an extra dummy jmp instruction to the
very next location after a call to HndWriteBarrierWorker.
This happens due to LLVM internal handling of the asm volatile ("" : : : "memory").
This change fixes it by replacing the barrier definition for x64 Unix by
__atomic_signal_fence(__ATOMIC_SEQ_CST)
This is a pure compiler only barrier and it doesn't introduce the side
effect like the asm volatile ("" : : : "memory").
Close dotnet#130698
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @agocke |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates CoreCLR’s VOLATILE_MEMORY_BARRIER() macro for GCC/Clang builds by replacing an empty asm volatile ("" : : : "memory") compiler barrier with __atomic_signal_fence(__ATOMIC_SEQ_CST) in both the main CoreCLR header and the GC environment copy, with the intent of avoiding undesirable codegen side-effects on Linux/x64 (per #130698).
Changes:
- Replace the GCC/Clang fallback
VOLATILE_MEMORY_BARRIER()implementation with__atomic_signal_fence(__ATOMIC_SEQ_CST)in CoreCLR’sinc/volatile.h. - Apply the same change to the GC’s corresponding
gc/env/volatile.hto keep the duplicated implementations aligned.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/coreclr/inc/volatile.h | Switches the GCC/Clang fallback compiler barrier macro to __atomic_signal_fence in the shared CoreCLR volatile helper header. |
| src/coreclr/gc/env/volatile.h | Mirrors the same barrier macro change in the GC environment’s copy of the volatile helper. |
jkotas
approved these changes
Aug 4, 2026
This was referenced Aug 4, 2026
Open
Member
Author
|
/ba-g the NativeAOT legs are timing out on all PRs |
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.
Currently the macro is defined as asm volatile ("" : : : "memory"). That caused a recent regression in HndWriteBarrier due to an added VolatileStore where clang adds an extra dummy jmp instruction to the very next location after a call to HndWriteBarrierWorker. This happens due to LLVM internal handling of the asm volatile ("" : : : "memory").
This change fixes it by replacing the barrier definition for x64 Unix by __atomic_signal_fence(__ATOMIC_SEQ_CST)
This is a pure compiler only barrier and it doesn't introduce the side effect like the asm volatile ("" : : : "memory").
Close #130698