-
Notifications
You must be signed in to change notification settings - Fork 12k
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
[nsan] Swap alignas and visibility order (NFC) #98933
Conversation
@llvm/pr-subscribers-compiler-rt-sanitizer Author: Nikita Popov (nikic) ChangesWhen preceded by SANITIZER_INTERFACE_ATTRIBUTE, use the ALIGNED macro instead of alignas, because clang 15 and older do not support this. See https://clang.godbolt.org/z/Wj1193xWK. This was broken by #96142 as part of other style changes. Full diff: https://github.com/llvm/llvm-project/pull/98933.diff 1 Files Affected:
diff --git a/compiler-rt/lib/nsan/nsan.cpp b/compiler-rt/lib/nsan/nsan.cpp
index e5a9b7a036e0e..10010495e3ee9 100644
--- a/compiler-rt/lib/nsan/nsan.cpp
+++ b/compiler-rt/lib/nsan/nsan.cpp
@@ -391,23 +391,23 @@ __nsan_dump_shadow_mem(const u8 *addr, size_t size_bytes, size_t bytes_per_line,
}
SANITIZER_INTERFACE_ATTRIBUTE
-alignas(16) thread_local uptr __nsan_shadow_ret_tag = 0;
+ALIGNED(16) thread_local uptr __nsan_shadow_ret_tag = 0;
SANITIZER_INTERFACE_ATTRIBUTE
-alignas(16) thread_local char __nsan_shadow_ret_ptr[kMaxVectorWidth *
- sizeof(__float128)];
+ALIGNED(16)
+thread_local char __nsan_shadow_ret_ptr[kMaxVectorWidth * sizeof(__float128)];
SANITIZER_INTERFACE_ATTRIBUTE
-alignas(16) thread_local uptr __nsan_shadow_args_tag = 0;
+ALIGNED(16) thread_local uptr __nsan_shadow_args_tag = 0;
// Maximum number of args. This should be enough for anyone (tm). An alternate
// scheme is to have the generated code create an alloca and make
// __nsan_shadow_args_ptr point ot the alloca.
constexpr const int kMaxNumArgs = 128;
SANITIZER_INTERFACE_ATTRIBUTE
-alignas(
- 16) thread_local char __nsan_shadow_args_ptr[kMaxVectorWidth * kMaxNumArgs *
- sizeof(__float128)];
+ALIGNED(16)
+thread_local char __nsan_shadow_args_ptr[kMaxVectorWidth * kMaxNumArgs *
+ sizeof(__float128)];
enum ContinuationType { // Keep in sync with instrumentation pass.
kContinueWithShadow = 0,
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
When preceded by SANITIZER_INTERFACE_ATTRIBUTE, use the ALIGNED macro instead of alignas, because clang 15 and older does not support this. See https://clang.godbolt.org/z/Wj1193xWK.
We already require support for We could also make |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.
cc: @vitalybuka |
The problem here is not alignas in general, but a very specific pattern that only occurs inside nsan. You want to look for
As far as I know, compiler-rt is subject to the LLVM monorepo host compiler requirements (https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library). Only the libcxx and libcxxabi projects are exempt from these. compiler-rt is commonly used by compilers other than clang, and the host compiler used to build it has no relation to the toolchain it will be part of. For such uses, only LLVM and compiler-rt will be built, but clang will generally not be built. In any case, changing the host compiler requirements for compiler-rt would require an RFC. |
OK, I see. The issue is that
|
Created #98958 and #98959 to clean up some |
Good point, done! |
Use `alignas(16) SANITIZER_INTERFACE_ATTRIBUTE` instead of `SANITIZER_INTERFACE_ATTRIBUTE alignas(16)`, as the former is not supported prior to clang 16. See https://clang.godbolt.org/z/Wj1193xWK. This was broken by llvm#96142 as part of other style changes.
Update to LLVM 19 Related changes: * rust-lang#127605 * rust-lang#127613 * rust-lang#127654 * rust-lang#128141 * llvm/llvm-project#98933 try-job: dist-x86_64-apple try-job: dist-apple-various try-job: x86_64-apple-1 try-job: x86_64-apple-2 try-job: dist-aarch64-apple try-job: aarch64-apple
Update to LLVM 19 Related changes: * rust-lang#127605 * rust-lang#127613 * rust-lang#127654 * rust-lang#128141 * llvm/llvm-project#98933 try-job: x86_64-msvc try-job: i686-msvc try-job: x86_64-msvc-ext try-job: dist-x86_64-msvc try-job: dist-i686-msvc try-job: dist-aarch64-msvc try-job: dist-x86_64-msvc-alt
Update to LLVM 19 Related changes: * rust-lang#127605 * rust-lang#127613 * rust-lang#127654 * rust-lang#128141 * llvm/llvm-project#98933 try-job: i686-mingw try-job: x86_64-mingw try-job: dist-i686-mingw try-job: dist-x86_64-mingw
Summary: Use `alignas(16) SANITIZER_INTERFACE_ATTRIBUTE` instead of `SANITIZER_INTERFACE_ATTRIBUTE alignas(16)`, as the former is not supported prior to clang 16. See https://clang.godbolt.org/z/Wj1193xWK. This was broken by #96142 as part of other style changes. Test Plan: Reviewers: Subscribers: Tasks: Tags: Differential Revision: https://phabricator.intern.facebook.com/D60250864
Update to LLVM 19 The LLVM 19.1.0 final release is planned for Sep 3rd. The rustc 1.82 stable release will be on Oct 17th. The unstable MC/DC coverage support is temporarily broken by this update. It will be restored by rust-lang#126733. The implementation changed substantially in LLVM 19, and there are no plans to support both the LLVM 18 and LLVM 19 implementation at the same time. Compatibility note for wasm: > WebAssembly target support for the `multivalue` target feature has changed when upgrading to LLVM 19. Support for generating functions with multiple returns no longer works and `-Ctarget-feature=+multivalue` has a different meaning than it did in LLVM 18 and prior. The WebAssembly target features `multivalue` and `reference-types` are now both enabled by default, but generated code is not affected by default. These features being enabled are encoded in the `target_features` custom section and may affect downstream tooling such as `wasm-opt` consuming the module, but the actual generated WebAssembly will continue to not use either `multivalue` or `reference-types` by default. There is no longer any supported means to generate a module that has a function with multiple returns. Related changes: * rust-lang#127605 * rust-lang#127613 * rust-lang#127654 * rust-lang#128141 * llvm/llvm-project#98933 Fixes rust-lang#121444. Fixes rust-lang#128212.
Update to LLVM 19 The LLVM 19.1.0 final release is planned for Sep 3rd. The rustc 1.82 stable release will be on Oct 17th. The unstable MC/DC coverage support is temporarily broken by this update. It will be restored by rust-lang#126733. The implementation changed substantially in LLVM 19, and there are no plans to support both the LLVM 18 and LLVM 19 implementation at the same time. Compatibility note for wasm: > WebAssembly target support for the `multivalue` target feature has changed when upgrading to LLVM 19. Support for generating functions with multiple returns no longer works and `-Ctarget-feature=+multivalue` has a different meaning than it did in LLVM 18 and prior. The WebAssembly target features `multivalue` and `reference-types` are now both enabled by default, but generated code is not affected by default. These features being enabled are encoded in the `target_features` custom section and may affect downstream tooling such as `wasm-opt` consuming the module, but the actual generated WebAssembly will continue to not use either `multivalue` or `reference-types` by default. There is no longer any supported means to generate a module that has a function with multiple returns. Related changes: * rust-lang#127605 * rust-lang#127613 * rust-lang#127654 * rust-lang#128141 * llvm/llvm-project#98933 Fixes rust-lang#121444. Fixes rust-lang#128212.
Update to LLVM 19 The LLVM 19.1.0 final release is planned for Sep 3rd. The rustc 1.82 stable release will be on Oct 17th. The unstable MC/DC coverage support is temporarily broken by this update. It will be restored by rust-lang#126733. The implementation changed substantially in LLVM 19, and there are no plans to support both the LLVM 18 and LLVM 19 implementation at the same time. Compatibility note for wasm: > WebAssembly target support for the `multivalue` target feature has changed when upgrading to LLVM 19. Support for generating functions with multiple returns no longer works and `-Ctarget-feature=+multivalue` has a different meaning than it did in LLVM 18 and prior. The WebAssembly target features `multivalue` and `reference-types` are now both enabled by default, but generated code is not affected by default. These features being enabled are encoded in the `target_features` custom section and may affect downstream tooling such as `wasm-opt` consuming the module, but the actual generated WebAssembly will continue to not use either `multivalue` or `reference-types` by default. There is no longer any supported means to generate a module that has a function with multiple returns. Related changes: * rust-lang#127605 * rust-lang#127613 * rust-lang#127654 * rust-lang#128141 * llvm/llvm-project#98933 Fixes rust-lang#121444. Fixes rust-lang#128212.
Update to LLVM 19 The LLVM 19.1.0 final release is planned for Sep 3rd. The rustc 1.82 stable release will be on Oct 17th. The unstable MC/DC coverage support is temporarily broken by this update. It will be restored by rust-lang/rust#126733. The implementation changed substantially in LLVM 19, and there are no plans to support both the LLVM 18 and LLVM 19 implementation at the same time. Compatibility note for wasm: > WebAssembly target support for the `multivalue` target feature has changed when upgrading to LLVM 19. Support for generating functions with multiple returns no longer works and `-Ctarget-feature=+multivalue` has a different meaning than it did in LLVM 18 and prior. The WebAssembly target features `multivalue` and `reference-types` are now both enabled by default, but generated code is not affected by default. These features being enabled are encoded in the `target_features` custom section and may affect downstream tooling such as `wasm-opt` consuming the module, but the actual generated WebAssembly will continue to not use either `multivalue` or `reference-types` by default. There is no longer any supported means to generate a module that has a function with multiple returns. Related changes: * rust-lang/rust#127605 * rust-lang/rust#127613 * rust-lang/rust#127654 * rust-lang/rust#128141 * llvm/llvm-project#98933 Fixes rust-lang/rust#121444. Fixes rust-lang/rust#128212.
Update to LLVM 19 The LLVM 19.1.0 final release is planned for Sep 3rd. The rustc 1.82 stable release will be on Oct 17th. The unstable MC/DC coverage support is temporarily broken by this update. It will be restored by rust-lang/rust#126733. The implementation changed substantially in LLVM 19, and there are no plans to support both the LLVM 18 and LLVM 19 implementation at the same time. Compatibility note for wasm: > WebAssembly target support for the `multivalue` target feature has changed when upgrading to LLVM 19. Support for generating functions with multiple returns no longer works and `-Ctarget-feature=+multivalue` has a different meaning than it did in LLVM 18 and prior. The WebAssembly target features `multivalue` and `reference-types` are now both enabled by default, but generated code is not affected by default. These features being enabled are encoded in the `target_features` custom section and may affect downstream tooling such as `wasm-opt` consuming the module, but the actual generated WebAssembly will continue to not use either `multivalue` or `reference-types` by default. There is no longer any supported means to generate a module that has a function with multiple returns. Related changes: * rust-lang/rust#127605 * rust-lang/rust#127613 * rust-lang/rust#127654 * rust-lang/rust#128141 * llvm/llvm-project#98933 Fixes rust-lang/rust#121444. Fixes rust-lang/rust#128212.
Use
alignas(16) SANITIZER_INTERFACE_ATTRIBUTE
instead ofSANITIZER_INTERFACE_ATTRIBUTE alignas(16)
, as the former is not supported prior to clang 16. See https://clang.godbolt.org/z/Wj1193xWK.This was broken by #96142 as part of other style changes.