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/object-size.cpp

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

65 lines
2.2 KiB
C++
Raw Normal View History

Fix a bug in __builtin_object_size cast removal Apparently there are many cast kinds that may cause implicit pointer arithmetic to happen. In light of this, the cast ignoring logic introduced in r246877 has been changed to only ignore a small set of cast kinds, and a test for this behavior has been added. Thanks to Richard for catching this before it became a bug report. :) llvm-svn: 246890
2015-09-05 06:36:18 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm -o - %s | FileCheck %s
// C++-specific tests for __builtin_object_size
int gi;
[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 @_Z5test1v()
Fix a bug in __builtin_object_size cast removal Apparently there are many cast kinds that may cause implicit pointer arithmetic to happen. In light of this, the cast ignoring logic introduced in r246877 has been changed to only ignore a small set of cast kinds, and a test for this behavior has been added. Thanks to Richard for catching this before it became a bug report. :) llvm-svn: 246890
2015-09-05 06:36:18 +08:00
void test1() {
// Guaranteeing that our cast removal logic doesn't break more interesting
// cases.
struct A { int a; };
struct B { int b; };
struct C: public A, public B {};
C c;
// CHECK: store i32 8
gi = __builtin_object_size(&c, 0);
// CHECK: store i32 8
gi = __builtin_object_size((A*)&c, 0);
// CHECK: store i32 4
gi = __builtin_object_size((B*)&c, 0);
// CHECK: store i32 8
gi = __builtin_object_size((char*)&c, 0);
// CHECK: store i32 8
gi = __builtin_object_size((char*)(A*)&c, 0);
// CHECK: store i32 4
gi = __builtin_object_size((char*)(B*)&c, 0);
}
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +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 @_Z5test2v()
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +08:00
void test2() {
struct A { char buf[16]; };
struct B : A {};
struct C { int i; B bs[1]; } *c;
Add a 'dynamic' parameter to the objectsize intrinsic This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
2019-01-31 04:34:35 +08:00
// CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, i1 false)
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +08:00
gi = __builtin_object_size(&c->bs[0], 0);
Add a 'dynamic' parameter to the objectsize intrinsic This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
2019-01-31 04:34:35 +08:00
// CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, i1 false)
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +08:00
gi = __builtin_object_size(&c->bs[0], 1);
Add a 'dynamic' parameter to the objectsize intrinsic This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
2019-01-31 04:34:35 +08:00
// CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 true, i1 true, i1 false)
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +08:00
gi = __builtin_object_size(&c->bs[0], 2);
// CHECK: store i32 16
gi = __builtin_object_size(&c->bs[0], 3);
Add a 'dynamic' parameter to the objectsize intrinsic This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
2019-01-31 04:34:35 +08:00
// CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, i1 false)
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +08:00
gi = __builtin_object_size((A*)&c->bs[0], 0);
// CHECK: store i32 16
gi = __builtin_object_size((A*)&c->bs[0], 1);
Add a 'dynamic' parameter to the objectsize intrinsic This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
2019-01-31 04:34:35 +08:00
// CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 true, i1 true, i1 false)
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +08:00
gi = __builtin_object_size((A*)&c->bs[0], 2);
// CHECK: store i32 16
gi = __builtin_object_size((A*)&c->bs[0], 3);
Add a 'dynamic' parameter to the objectsize intrinsic This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
2019-01-31 04:34:35 +08:00
// CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, i1 false)
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +08:00
gi = __builtin_object_size(&c->bs[0].buf[0], 0);
// CHECK: store i32 16
gi = __builtin_object_size(&c->bs[0].buf[0], 1);
Add a 'dynamic' parameter to the objectsize intrinsic This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
2019-01-31 04:34:35 +08:00
// CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 true, i1 true, i1 false)
Make __builtin_object_size more conservative r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
2015-10-16 09:49:01 +08:00
gi = __builtin_object_size(&c->bs[0].buf[0], 2);
// CHECK: store i32 16
gi = __builtin_object_size(&c->bs[0].buf[0], 3);
}