maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/code-coverage-tsan.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

13 lines
583 B
C
Raw Normal View History

Add -fprofile-update={atomic,prefer-atomic,single} GCC 7 introduced -fprofile-update={atomic,prefer-atomic} (prefer-atomic is for best efforts (some targets do not support atomics)) to increment counters atomically, which is exactly what we have done with -fprofile-instr-generate (D50867) and -fprofile-arcs (b5ef137c11b1cc6ae839ee75b49233825772bdd0). This patch adds the option to clang to surface the internal options at driver level. GCC 7 also turned on -fprofile-update=prefer-atomic when -pthread is specified, but it has performance regression (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307). So we don't follow suit. Differential Revision: https://reviews.llvm.org/D87737
2020-09-30 01:38:51 +08:00
/// -fprofile-update=atomic (implied by -fsanitize=thread) requires the
/// (potentially concurrent) counter updates to be atomic.
[gcov] Unify driver and CC1 option names for -ftest-coverage & -fprofile-arcs No need to use -femit-coverage-notes and -femit-coverage-data.
2020-10-20 13:17:32 +08:00
// RUN: %clang_cc1 %s -triple x86_64 -emit-llvm -fprofile-update=atomic -ftest-coverage -fprofile-arcs \
[gcov] Increment counters with atomicrmw if -fsanitize=thread Without this patch, `clang --coverage -fsanitize=thread` may fail spuriously because non-atomic counter increments can be detected as data races.
2020-08-29 07:32:35 +08:00
// RUN: -coverage-notes-file /dev/null -coverage-data-file /dev/null -o - | FileCheck %s
// CHECK-LABEL: void @foo()
/// Two counters are incremented by __tsan_atomic64_fetch_add.
NFC: update clang tests to check ordering and alignment for atomicrmw/cmpxchg. The ability to specify alignment was recently added, and it's an important property which we should ensure is set as expected by Clang. (Especially before making further changes to Clang's code in this area.) But, because it's on the end of the lines, the existing tests all ignore it. Therefore, update all the tests to also verify the expected alignment for atomicrmw and cmpxchg. While I was in there, I also updated uses of 'load atomic' and 'store atomic', and added the memory ordering, where that was missing.
2021-02-12 06:33:43 +08:00
// CHECK: atomicrmw add i64* {{.*}} @__llvm_gcov_ctr{{.*}} monotonic, align 8
Add -fprofile-update={atomic,prefer-atomic,single} GCC 7 introduced -fprofile-update={atomic,prefer-atomic} (prefer-atomic is for best efforts (some targets do not support atomics)) to increment counters atomically, which is exactly what we have done with -fprofile-instr-generate (D50867) and -fprofile-arcs (b5ef137c11b1cc6ae839ee75b49233825772bdd0). This patch adds the option to clang to surface the internal options at driver level. GCC 7 also turned on -fprofile-update=prefer-atomic when -pthread is specified, but it has performance regression (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307). So we don't follow suit. Differential Revision: https://reviews.llvm.org/D87737
2020-09-30 01:38:51 +08:00
// CHECK-NEXT: atomicrmw sub i32*
[gcov] Increment counters with atomicrmw if -fsanitize=thread Without this patch, `clang --coverage -fsanitize=thread` may fail spuriously because non-atomic counter increments can be detected as data races.
2020-08-29 07:32:35 +08:00
_Atomic(int) cnt;
void foo() { cnt--; }