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/mangle-blocks.c

24 lines
1.0 KiB
C
Raw Normal View History

CodeGen: correct mangling for blocks This addresses a regression introduced with SVN r219393. A block may be contained within another block. In such a scenario, we would end up within a BlockDecl, which is not a NamedDecl (as the names are synthesised). The cast to a NamedDecl of the DeclContext would then assert as the types are unrelated. Restore the mangling behaviour to that prior to SVN r219393. If the current block is contained within a BlockDecl, walk up to the parent DeclContext, recursively, until we have a non-BlockDecl. This is expected to be a NamedDecl. Add in a couple of asserts to ensure that the assumption that we only encounter a block within a NamedDecl or a BlockDecl. llvm-svn: 219696
2014-10-15 01:20:14 +08:00
// RUN: %clang_cc1 -triple i386-apple-ios -fblocks -emit-llvm -o - %s | FileCheck %s
void __assert_rtn(const char *, const char *, int, const char *)
__attribute__ (( noreturn ));
test: simplify test further Remove the use of an unnecessary function. NFC. llvm-svn: 219850
2014-10-16 05:37:52 +08:00
void (^mangle(void))(void) {
return ^{
void (^block)(void) = ^{
__assert_rtn(__func__, __FILE__, __LINE__, "mangle");
};
};
CodeGen: correct mangling for blocks This addresses a regression introduced with SVN r219393. A block may be contained within another block. In such a scenario, we would end up within a BlockDecl, which is not a NamedDecl (as the names are synthesised). The cast to a NamedDecl of the DeclContext would then assert as the types are unrelated. Restore the mangling behaviour to that prior to SVN r219393. If the current block is contained within a BlockDecl, walk up to the parent DeclContext, recursively, until we have a non-BlockDecl. This is expected to be a NamedDecl. Add in a couple of asserts to ensure that the assumption that we only encounter a block within a NamedDecl or a BlockDecl. llvm-svn: 219696
2014-10-15 01:20:14 +08:00
}
Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks Instead of always displaying the mangled name, try to do better and get something closer to regular functions. Recommit r287039 (that was reverted in r287039) with a tweak to be more generic, and test fixes! Differential Revision: https://reviews.llvm.org/D26522 llvm-svn: 287085
2016-11-16 15:07:28 +08:00
// CHECK: @__func__.__mangle_block_invoke_2 = private unnamed_addr constant [22 x i8] c"mangle_block_invoke_2\00", align 1
[CodeGen][ObjC] Build the global block structure before emitting the body of global block invoke functions. This commit fixes an infinite loop in IRGen that occurs when compiling the following code: void FUNC2() { static void (^const block1)(int) = ^(int a){ if (a--) block1(a); }; } This is how IRGen gets stuck in the infinite loop: 1. GenerateBlockFunction is called to emit the body of "block1". 2. GetAddrOfGlobalBlock is called to get the address of "block1". The function calls getAddrOfGlobalBlockIfEmitted to check whether the global block has been emitted. If it hasn't been emitted, it then tries to emit the body of the block function by calling GenerateBlockFunction, which goes back to step 1. This commit prevents the inifinite loop by building the global block in GenerateBlockFunction before emitting the body of the block function. rdar://problem/34541684 Differential Revision: https://reviews.llvm.org/D38118 llvm-svn: 314029
2017-09-23 05:32:06 +08:00
// CHECK: @.str{{.*}} = private unnamed_addr constant {{.*}}, align 1
// CHECK: @.str[[STR1:.*]] = private unnamed_addr constant [7 x i8] c"mangle\00", align 1
CodeGen: correct mangling for blocks This addresses a regression introduced with SVN r219393. A block may be contained within another block. In such a scenario, we would end up within a BlockDecl, which is not a NamedDecl (as the names are synthesised). The cast to a NamedDecl of the DeclContext would then assert as the types are unrelated. Restore the mangling behaviour to that prior to SVN r219393. If the current block is contained within a BlockDecl, walk up to the parent DeclContext, recursively, until we have a non-BlockDecl. This is expected to be a NamedDecl. Add in a couple of asserts to ensure that the assumption that we only encounter a block within a NamedDecl or a BlockDecl. llvm-svn: 219696
2014-10-15 01:20:14 +08:00
// CHECK: define internal void @__mangle_block_invoke(i8* %.block_descriptor)
// CHECK: define internal void @__mangle_block_invoke_2(i8* %.block_descriptor){{.*}}{
[CodeGen][ObjC] Build the global block structure before emitting the body of global block invoke functions. This commit fixes an infinite loop in IRGen that occurs when compiling the following code: void FUNC2() { static void (^const block1)(int) = ^(int a){ if (a--) block1(a); }; } This is how IRGen gets stuck in the infinite loop: 1. GenerateBlockFunction is called to emit the body of "block1". 2. GetAddrOfGlobalBlock is called to get the address of "block1". The function calls getAddrOfGlobalBlockIfEmitted to check whether the global block has been emitted. If it hasn't been emitted, it then tries to emit the body of the block function by calling GenerateBlockFunction, which goes back to step 1. This commit prevents the inifinite loop by building the global block in GenerateBlockFunction before emitting the body of the block function. rdar://problem/34541684 Differential Revision: https://reviews.llvm.org/D38118 llvm-svn: 314029
2017-09-23 05:32:06 +08:00
// CHECK: call void @__assert_rtn(i8* getelementptr inbounds ([22 x i8], [22 x i8]* @__func__.__mangle_block_invoke_2, i32 0, i32 0), i8* getelementptr inbounds {{.*}}, i32 9, i8* getelementptr inbounds ([7 x i8], [7 x i8]* @.str[[STR1]], i32 0, i32 0))
CodeGen: correct mangling for blocks This addresses a regression introduced with SVN r219393. A block may be contained within another block. In such a scenario, we would end up within a BlockDecl, which is not a NamedDecl (as the names are synthesised). The cast to a NamedDecl of the DeclContext would then assert as the types are unrelated. Restore the mangling behaviour to that prior to SVN r219393. If the current block is contained within a BlockDecl, walk up to the parent DeclContext, recursively, until we have a non-BlockDecl. This is expected to be a NamedDecl. Add in a couple of asserts to ensure that the assumption that we only encounter a block within a NamedDecl or a BlockDecl. llvm-svn: 219696
2014-10-15 01:20:14 +08:00
// CHECK: }