https://llvm.org/bugs/show_bug.cgi?id=27887
Bug ID: 27887
Summary: Arguments marked as ns_consumed should not be released
if forwarded to another ns_consumed argument
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sdefre...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Trying to use "ns_consumed" in a template class, I found that a function taking
an argument marked as "ns_consumed" and forwarding it to another function
taking it as "ns_consumed" too behave differently in constructor and plain
functions.
With free functions, no memory management happens (as expected):
$ cat x.mm
void foo(id __attribute__((ns_consumed)) x);
void bar(id __attribute__((ns_consumed)) x) {
foo(x);
}
$ llvm-build/Release+Asserts/bin/clang++ -S -o - x.mm -fomit-frame-pointer
-fobjc-arc -Os -fno-exceptions --std=c++11
.section __TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 11
.globl __Z3barU11ns_consumedP11objc_object
__Z3barU11ns_consumedP11objc_object: ## @_Z3barU11ns_consumedP11objc_object
.cfi_startproc
## BB#0: ## %entry
pushq %rax
Ltmp0:
.cfi_def_cfa_offset 16
callq __Z3fooU11ns_consumedP11objc_object
popq %rax
retq
.cfi_endproc
.section __DATA,__objc_imageinfo,regular,no_dead_strip
L_OBJC_IMAGE_INFO:
.long 0
.long 64
.subsections_via_symbols
However, for constructors (I've not checked for other methods), there is a call
to objc_release that I do not expect (as there are no corresponding
obj_retain):
$ cat y.mm
struct a {
a(id __attribute__((ns_consumed)) x) noexcept;
};
struct b : a {
b(id __attribute__((ns_consumed)) x);
};
b::b(id __attribute__((ns_consumed)) x) : a(x) {}
$ llvm-build/Release+Asserts/bin/clang++ -S -o - y.mm -fomit-frame-pointer
-fobjc-arc -Os -fno-exceptions --std=c++11
.section __TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 11
.globl __ZN1bC2EU11ns_consumedP11objc_object
.p2align 1, 0x90
__ZN1bC2EU11ns_consumedP11objc_object: ##
@_ZN1bC2EU11ns_consumedP11objc_object
.cfi_startproc
## BB#0: ## %entry
jmp __ZN1aC2EU11ns_consumedP11objc_object ## TAILCALL
.cfi_endproc
.globl __ZN1bC1EU11ns_consumedP11objc_object
.p2align 1, 0x90
__ZN1bC1EU11ns_consumedP11objc_object: ##
@_ZN1bC1EU11ns_consumedP11objc_object
.cfi_startproc
## BB#0: ## %entry
pushq %rbx
Ltmp0:
.cfi_def_cfa_offset 16
Ltmp1:
.cfi_offset %rbx, -16
movq %rsi, %rbx
callq __ZN1aC2EU11ns_consumedP11objc_object
movq %rbx, %rdi
popq %rbx
jmpq *_objc_release@GOTPCREL(%rip) ## TAILCALL
.cfi_endproc
.section __DATA,__objc_imageinfo,regular,no_dead_strip
L_OBJC_IMAGE_INFO:
.long 0
.long 64
.subsections_via_symbols
I would expect the code generated to be the same here as is generated with
-fno-objc-arc.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
