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
}
// CHECK: @__func__.__mangle_block_invoke_2 = private unnamed_addr constant [24 x i8] c"__mangle_block_invoke_2\00", align 1
// CHECK: @.str = private unnamed_addr constant {{.*}}, align 1
Changed renaming of local symbols by inserting a dot vefore the numeric suffix details in http://reviews.llvm.org/D9483 goes with llvm checkin r237150 llvm-svn: 237151
2015-05-13 00:48:43 +08:00
// CHECK: @.str.1 = 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){{.*}}{
Changed renaming of local symbols by inserting a dot vefore the numeric suffix details in http://reviews.llvm.org/D9483 goes with llvm checkin r237150 llvm-svn: 237151
2015-05-13 00:48:43 +08:00
// CHECK: call void @__assert_rtn(i8* getelementptr inbounds ([24 x i8], [24 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.1, 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: }