-
Notifications
You must be signed in to change notification settings - Fork 12.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clang crashes on assignment of ObjC @​protocol() object to runtime structure #6503
Comments
I don't know how relevant this is, but I get a lot of warnings from GCC in bits of Sema that appear in that stack trace complaining that dereferencing type-punned pointer will break strict-aliasing rules. Maybe -fno-strict-aliasing would fix this? If so, then whoever committed all of the code that causes these warnings should probably fix them (I thought we weren't allowed to commit code to clang that didn't compile without warnings, anyway?) |
Not sure when this was fixed, but this construct works now, raising a warning that there is a missing cast. I think that warnings that the results of @encode(), @protocol(), and @selector() expressions are spurious, but this may be an implementation issue (they're all constant with the GNU runtime, at least), rather than a language issue. |
Under some conditions, a trivial `mov xN xN` instruction was emitted on tail calls. Consider the following code: ``` class Test { public: virtual void f() {} }; void call_f(Test *t) { t->f(); } ``` Correponding assembly: ``` _Z6call_fP4Test: ldr x16, [x0] mov x17, x0 movk x17, llvm#6503, lsl llvm#48 autda x16, x17 ldr x1, [x16] =====> mov x16, x16 movk x16, llvm#54167, lsl llvm#48 braa x1, x16 ``` This patch makes such movs being omitted. Co-authored-by: Anatoly Trosinenko <atrosinenko@accesssoftek.com>
Under some conditions, a trivial `mov xN xN` instruction was emitted on tail calls. Consider the following code: ``` class Test { public: virtual void f() {} }; void call_f(Test *t) { t->f(); } ``` Correponding assembly: ``` _Z6call_fP4Test: ldr x16, [x0] mov x17, x0 movk x17, #6503, lsl #48 autda x16, x17 ldr x1, [x16] =====> mov x16, x16 movk x16, #54167, lsl #48 braa x1, x16 ``` This patch makes such movs being omitted. Co-authored-by: Anatoly Trosinenko <atrosinenko@accesssoftek.com>
…9100) Under some conditions, a trivial `mov xN xN` instruction was emitted on tail calls. Consider the following code: ``` class Test { public: virtual void f() {} }; void call_f(Test *t) { t->f(); } ``` Correponding assembly: ``` _Z6call_fP4Test: ldr x16, [x0] mov x17, x0 movk x17, llvm#6503, lsl llvm#48 autda x16, x17 ldr x1, [x16] =====> mov x16, x16 movk x16, llvm#54167, lsl llvm#48 braa x1, x16 ``` This patch makes such movs being omitted. Co-authored-by: Anatoly Trosinenko <atrosinenko@accesssoftek.com>
Extended Description
Hello,
I recently stumbled upon an odd crash with recent clang trunk (r94363) on a 64bit Linux machine, when I was trying to debug some problems with the GNUstep Objective-C runtime. In particular, clang is crashing for me when you try to assign a @protocol()-object to the corresponding runtime structure like this:
struct objc_protocol *foo = @protocol(Foo);
I have attached a test case that demonstrates the problem with a reduced definition of struct objc_protocol and the corresponding backtrace from gdb.
I'm also confused as to why clang tries to print a warning here. If I replace
the above with
void foo = (void)@protocol(TestProtocol);
It will print the following error:
protocol.m:12:13: error: initializer element is not a compile-time constant
It would be great if someone had an idea about what is going wrong here
The text was updated successfully, but these errors were encountered: