maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/atomicinit.cpp

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

107 lines
3.1 KiB
C++
Raw Normal View History

[Clang] Disable new PM for tests that use optimization level -O1, -O2 and -O3 Tests that use -O1, -O2 and -O3 would often produce different results with the new pass manager which makes these tests fail. Disable new PM explicitly for these tests. Differential Revision: https://reviews.llvm.org/D58375 llvm-svn: 362580
2019-06-05 11:17:11 +08:00
// RUN: %clang_cc1 %s -emit-llvm -O1 -fno-experimental-new-pass-manager -o - -triple=i686-apple-darwin9 -std=c++11 | FileCheck %s
PR18097: Support initializing an _Atomic(T) from an object of C++ class type T or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
2014-07-31 14:31:19 +08:00
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-31 12:45:56 +08:00
// CHECK-DAG: @PR22043 ={{.*}} local_unnamed_addr global i32 0, align 4
Sema: Permit an atomic type to be initialized by the same atomic type We forgot a conversion step when initializing an atomic type with an rvalue of the same type. This fixes PR22043. llvm-svn: 224902
2014-12-29 05:47:31 +08:00
typedef _Atomic(int) AtomicInt;
AtomicInt PR22043 = AtomicInt();
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-31 12:45:56 +08:00
// CHECK-DAG: @_ZN7PR180978constant1aE ={{.*}} local_unnamed_addr global { i16, i8 } { i16 1, i8 6 }, align 4
// CHECK-DAG: @_ZN7PR180978constant1bE ={{.*}} local_unnamed_addr global { i16, i8 } { i16 2, i8 6 }, align 4
// CHECK-DAG: @_ZN7PR180978constant1cE ={{.*}} local_unnamed_addr global { i16, i8 } { i16 3, i8 6 }, align 4
// CHECK-DAG: @_ZN7PR180978constant1yE ={{.*}} local_unnamed_addr global { { i16, i8 }, i32 } { { i16, i8 } { i16 4, i8 6 }, i32 5 }, align 4
PR18097: Support initializing an _Atomic(T) from an object of C++ class type T or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
2014-07-31 14:31:19 +08:00
Allow c++ initialisers to initialise _Atomic fields. llvm-svn: 154499
2012-04-11 23:29:15 +08:00
struct A {
_Atomic(int) i;
A(int j);
void v(int j);
};
// Storing to atomic values should be atomic
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: store atomic i32 {{.*}} seq_cst, align 4
Allow c++ initialisers to initialise _Atomic fields. llvm-svn: 154499
2012-04-11 23:29:15 +08:00
void A::v(int j) { i = j; }
// Initialising atomic values should not be atomic
// CHECK-NOT: store atomic
A::A(int j) : i(j) {}
Make __atomic_init() (soon to be __c11_atomic_init()) work with non-scalar types. llvm-svn: 154507
2012-04-12 01:24:05 +08:00
struct B {
int i;
B(int x) : i(x) {}
};
_Atomic(B) b;
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-31 12:45:56 +08:00
// CHECK-LABEL: define{{.*}} void @_Z11atomic_initR1Ai
Make __atomic_init() (soon to be __c11_atomic_init()) work with non-scalar types. llvm-svn: 154507
2012-04-12 01:24:05 +08:00
void atomic_init(A& a, int i) {
// CHECK-NOT: atomic
Revert "Revert "As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there."" This reapplies: 8ff85ed905a7306977d07a5cd67ab4d5a56fafb4 Original commit message: As a follow-up to my initial mail to llvm-dev here's a first pass at the O1 described there. This change doesn't include any change to move from selection dag to fast isel and that will come with other numbers that should help inform that decision. There also haven't been any real debuggability studies with this pipeline yet, this is just the initial start done so that people could see it and we could start tweaking after. Test updates: Outside of the newpm tests most of the updates are coming from either optimization passes not run anymore (and without a compelling argument at the moment) that were largely used for canonicalization in clang. Original post: http://lists.llvm.org/pipermail/llvm-dev/2019-April/131494.html Tags: #llvm Differential Revision: https://reviews.llvm.org/D65410 This reverts commit c9ddb02659e3ece7a0d9d6b4dac7ceea4ae46e6d.
2019-11-27 12:28:52 +08:00
// CHECK: call void @_ZN1BC1Ei
Update recently-added test to use new __c11_ form of atomic builtins. llvm-svn: 154514
2012-04-12 02:00:46 +08:00
__c11_atomic_init(&b, B(i));
Fix some i1/i8 confusion within _Atomic(bool) in IR generation, both in general (such an atomic has boolean representation) and specifically for IR generation of __c11_atomic_init. The latter also means actually using initialization semantics for this initialization, rather than just creating a store. On a related note, make sure we actually put in non-atomic-to-atomic conversions when performing an implicit conversion sequence. IR generation is far too kind here, but we still want the ASTs to make sense. llvm-svn: 154612
2012-04-13 04:42:30 +08:00
// CHECK-NEXT: ret void
Make __atomic_init() (soon to be __c11_atomic_init()) work with non-scalar types. llvm-svn: 154507
2012-04-12 01:24:05 +08:00
}
Fix some i1/i8 confusion within _Atomic(bool) in IR generation, both in general (such an atomic has boolean representation) and specifically for IR generation of __c11_atomic_init. The latter also means actually using initialization semantics for this initialization, rather than just creating a store. On a related note, make sure we actually put in non-atomic-to-atomic conversions when performing an implicit conversion sequence. IR generation is far too kind here, but we still want the ASTs to make sense. llvm-svn: 154612
2012-04-13 04:42:30 +08:00
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-31 12:45:56 +08:00
// CHECK-LABEL: define{{.*}} void @_Z16atomic_init_boolPU7_Atomicbb
Fix some i1/i8 confusion within _Atomic(bool) in IR generation, both in general (such an atomic has boolean representation) and specifically for IR generation of __c11_atomic_init. The latter also means actually using initialization semantics for this initialization, rather than just creating a store. On a related note, make sure we actually put in non-atomic-to-atomic conversions when performing an implicit conversion sequence. IR generation is far too kind here, but we still want the ASTs to make sense. llvm-svn: 154612
2012-04-13 04:42:30 +08:00
void atomic_init_bool(_Atomic(bool) *ab, bool b) {
// CHECK-NOT: atomic
// CHECK: {{zext i1.*to i8}}
// CHECK-NEXT: store i8
__c11_atomic_init(ab, b);
// CHECK-NEXT: ret void
}
struct AtomicBoolMember {
_Atomic(bool) ab;
AtomicBoolMember(bool b);
};
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-31 12:45:56 +08:00
// CHECK-LABEL: define{{.*}} void @_ZN16AtomicBoolMemberC2Eb
Update test to account for r276604 llvm-svn: 276607
2016-07-25 12:47:45 +08:00
// CHECK: zext i1 {{.*}} to i8
// CHECK: store i8
Fix some i1/i8 confusion within _Atomic(bool) in IR generation, both in general (such an atomic has boolean representation) and specifically for IR generation of __c11_atomic_init. The latter also means actually using initialization semantics for this initialization, rather than just creating a store. On a related note, make sure we actually put in non-atomic-to-atomic conversions when performing an implicit conversion sequence. IR generation is far too kind here, but we still want the ASTs to make sense. llvm-svn: 154612
2012-04-13 04:42:30 +08:00
// CHECK-NEXT: ret void
AtomicBoolMember::AtomicBoolMember(bool b) : ab(b) { }
PR18097: Support initializing an _Atomic(T) from an object of C++ class type T or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
2014-07-31 14:31:19 +08:00
namespace PR18097 {
namespace dynamic {
struct X {
X(int);
short n;
char c;
};
// CHECK-LABEL: define {{.*}} @__cxx_global_var_init
[CodeGen] Apply 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments. * Adds 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments * Gates 'nonnull' on -f(no-)delete-null-pointer-checks * Introduces this-nonnull.cpp and microsoft-abi-this-nullable.cpp tests to explicitly test the behavior of this change * Refactors hundreds of over-constrained clang tests to permit these attributes, where needed * Updates Clang12 patch notes mentioning this change Reviewed-by: rsmith, jdoerfert Differential Revision: https://reviews.llvm.org/D17993
2020-11-17 07:04:55 +08:00
// CHECK: call void @_ZN7PR180977dynamic1XC1Ei({{.*}}* nonnull {{[^,]*}} @_ZN7PR180977dynamic1aE, i32 1)
PR18097: Support initializing an _Atomic(T) from an object of C++ class type T or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
2014-07-31 14:31:19 +08:00
_Atomic(X) a = X(1);
// CHECK-LABEL: define {{.*}} @__cxx_global_var_init
[CodeGen] Apply 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments. * Adds 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments * Gates 'nonnull' on -f(no-)delete-null-pointer-checks * Introduces this-nonnull.cpp and microsoft-abi-this-nullable.cpp tests to explicitly test the behavior of this change * Refactors hundreds of over-constrained clang tests to permit these attributes, where needed * Updates Clang12 patch notes mentioning this change Reviewed-by: rsmith, jdoerfert Differential Revision: https://reviews.llvm.org/D17993
2020-11-17 07:04:55 +08:00
// CHECK: call void @_ZN7PR180977dynamic1XC1Ei({{.*}}* nonnull {{[^,]*}} @_ZN7PR180977dynamic1bE, i32 2)
PR18097: Support initializing an _Atomic(T) from an object of C++ class type T or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
2014-07-31 14:31:19 +08:00
_Atomic(X) b(X(2));
// CHECK-LABEL: define {{.*}} @__cxx_global_var_init
[CodeGen] Apply 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments. * Adds 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments * Gates 'nonnull' on -f(no-)delete-null-pointer-checks * Introduces this-nonnull.cpp and microsoft-abi-this-nullable.cpp tests to explicitly test the behavior of this change * Refactors hundreds of over-constrained clang tests to permit these attributes, where needed * Updates Clang12 patch notes mentioning this change Reviewed-by: rsmith, jdoerfert Differential Revision: https://reviews.llvm.org/D17993
2020-11-17 07:04:55 +08:00
// CHECK: call void @_ZN7PR180977dynamic1XC1Ei({{.*}}* nonnull {{[^,]*}} @_ZN7PR180977dynamic1cE, i32 3)
PR18097: Support initializing an _Atomic(T) from an object of C++ class type T or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
2014-07-31 14:31:19 +08:00
_Atomic(X) c{X(3)};
struct Y {
_Atomic(X) a;
_Atomic(int) b;
};
// CHECK-LABEL: define {{.*}} @__cxx_global_var_init
[CodeGen] Apply 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments. * Adds 'nonnull' and 'dereferenceable(N)' to 'this' pointer arguments * Gates 'nonnull' on -f(no-)delete-null-pointer-checks * Introduces this-nonnull.cpp and microsoft-abi-this-nullable.cpp tests to explicitly test the behavior of this change * Refactors hundreds of over-constrained clang tests to permit these attributes, where needed * Updates Clang12 patch notes mentioning this change Reviewed-by: rsmith, jdoerfert Differential Revision: https://reviews.llvm.org/D17993
2020-11-17 07:04:55 +08:00
// CHECK: call void @_ZN7PR180977dynamic1XC1Ei({{.*}}* {{[^,]*}} getelementptr inbounds ({{.*}}, {{.*}}* @_ZN7PR180977dynamic1yE, i32 0, i32 0), i32 4)
Test case updates for explicit type parameter to the gep operator llvm-svn: 232187
2015-03-14 02:21:46 +08:00
// CHECK: store i32 5, i32* getelementptr inbounds ({{.*}}, {{.*}}* @_ZN7PR180977dynamic1yE, i32 0, i32 1)
PR18097: Support initializing an _Atomic(T) from an object of C++ class type T or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
2014-07-31 14:31:19 +08:00
Y y = { X(4), 5 };
}
// CHECKs at top of file.
namespace constant {
struct X {
constexpr X(int n) : n(n) {}
short n;
char c = 6;
};
_Atomic(X) a = X(1);
_Atomic(X) b(X(2));
_Atomic(X) c{X(3)};
struct Y {
_Atomic(X) a;
_Atomic(int) b;
};
Y y = { X(4), 5 };
}
}