-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mono] Second try at using C11 atomics #91808
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
6aa48ba
to
2c2e131
Compare
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
"Build linux-arm64 Release AllSubsets_Mono_LLVMFullAot_RuntimeTests llvmfullaot failed" is failing with
which looks similar to https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1780747 which says that clang 6.0.1 had some kind of a regression. Are we running some really old clang? |
should we revert the atomics pr while we sort this out? |
reverting in #91812 while we figure out the failure |
I kind of suspect the LLVMFullAot lane is failing because it's using the GCC In GCC Clang output: https://godbolt.org/z/8WP7hbvG1 Clang header: https://clang.llvm.org/doxygen/stdatomic_8h_source.html Note it defines the standard function as Updated godbolt: https://godbolt.org/z/Kq6qrWTjW |
I merged |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@directhex do you think it's safe to do |
@lambdageek it seems fair to try for our infra. I can't guarantee it working on anyone else's. |
The include path didn't help on linux-arm64 llvmfullaot. Its clear what the problem is, but I have no idea how to fix the include paths without a repro environment. |
New approach. The offsets tool doesn't actually need to look at anything in atomic.h, so just ifdef it out if we're generating offsets. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
It will expand to `_Bool` in C11 and mess things up. Use `boolean` instead Fixes dotnet#91779
dotnet#91489)" (dotnet#91812)" This reverts commit 2157e37.
8661be9
to
edf1850
Compare
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
the offset tool doesn't need to see the inlined atomic operations at all Also, refactor the ifdef logic up front and define one of MONO_USE_C11_ATOMIC, MONO_USE_WIN32_ATOMIC, MONO_USE_GCC_ATOMIC or MONO_USE_EMULATED_ATOMIC depending on what we will use
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
bool
in icall sig macros
I'm back to shaving this yak. New approach: don't try to make the offsets tool smarter, just pretend we're going to use emulated atomics. The offsets tool doesn't actually need to see the implementations of mono's atomic operations, so just avoid the whole problem. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This reverts commit edf1850.
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
@vargaz @jkoritzinsky @akoeplinger I assume your reviews are still 👍 ? Nothing substantially different - just some refactoring to not show offsets-tools the atomic implementations (it doesn't need to see function bodies) |
I believe the remaining failures are unrelated |
For each platform decide if we will use C11 standard atomics, Win32 API atomics, GCC atomic intrinsics or emulated atomics.
To use C11 atomics we generally want them to be lock-free for the primitive types we care about (that is,
ATOMIC_LONG_LONG_LOCK_FREE == 2
not1
and similarly for other macros) because otherwise we cannot be sure if the atomic might use a global lock in which case we could have thread suspend problems if both the GC and the rest of the runtime use an atomic at the same time.On win32, use the win32 atomics until MSVC atomics support is not experimental, or we update our build to pass
/experimental:c11atomics
; and also until we build our C++ code with C++23 or later (otherwise MSVC will complain about including stdatomic.h)If the header gets included while we're generating offsets using
offsets-tool.py
, pretend we're using emulated atomics. On some Linux configurations, the libclang that we use ends up picking up the platformatomic.h
header, not the clang one, and then errors out on their underlying implementation.Replace the use of
bool
in some macros in Mono - it will expand to_Bool
in C11 and mess things up.Use
boolean
insteadFixes [Android][arm64] Use of undeclared identifier 'ICALL_SIG_TYPE__Bool' #91779