maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenObjC/property-aggregate.m

32 lines
927 B
Mathematica
Raw Normal View History

Make -fobjc-nonfragile-abi the -cc1 default, since it's the increasingly prevailing case to the point that new features like ARC don't even support the fragile ABI anymore. This required a little bit of reshuffling with exceptions because a check was assuming that ObjCNonFragileABI was only being set in ObjC mode, and that's actually a bit obnoxious to do. Most, though, it involved a perl script to translate a ton of test cases. Mostly no functionality change for driver users, although there are corner cases with disabling language-specific exceptions that we should handle more correctly now. llvm-svn: 140957
2011-10-02 09:16:38 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck %s
Don't use native atomics on ivars whose size is not a power of two, even on architectures that support unaligned access (which is the only way this is otherwise legal, given that ivars apparently do not honor alignment attributes). llvm-svn: 139590
2011-09-13 15:33:34 +08:00
// This structure's size is not a power of two, so the property does
// not get native atomics, even though x86-64 can do unaligned atomics
// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
Turn off the generation of unaligned atomic load/store; I'm going to explicitly error out on such cases in the backend, at least for the moment. llvm-svn: 139640
2011-09-14 04:48:30 +08:00
// FIXME: But we don't at the moment; the backend doesn't know how to generate
// correct code.
Don't use native atomics on ivars whose size is not a power of two, even on architectures that support unaligned access (which is the only way this is otherwise legal, given that ivars apparently do not honor alignment attributes). llvm-svn: 139590
2011-09-13 15:33:34 +08:00
struct s4 { char c[4]; };
@interface Test0
@property struct s3 s3;
@property struct s4 s4;
@end
@implementation Test0
@synthesize s3, s4;
@end
// CHECK: define internal i24 @"\01-[Test0 s3]"(
// CHECK: call void @objc_copyStruct
// CHECK: define internal void @"\01-[Test0 setS3:]"(
// CHECK: call void @objc_copyStruct
// CHECK: define internal i32 @"\01-[Test0 s4]"(
Turn off the generation of unaligned atomic load/store; I'm going to explicitly error out on such cases in the backend, at least for the moment. llvm-svn: 139640
2011-09-14 04:48:30 +08:00
// CHECK: call void @objc_copyStruct
Don't use native atomics on ivars whose size is not a power of two, even on architectures that support unaligned access (which is the only way this is otherwise legal, given that ivars apparently do not honor alignment attributes). llvm-svn: 139590
2011-09-13 15:33:34 +08:00
// CHECK: define internal void @"\01-[Test0 setS4:]"(
Turn off the generation of unaligned atomic load/store; I'm going to explicitly error out on such cases in the backend, at least for the moment. llvm-svn: 139640
2011-09-14 04:48:30 +08:00
// CHECK: call void @objc_copyStruct