Created attachment 4104 [details] Testcase to demonstrate the problem 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
Created attachment 4105 [details] backtrace for the clang crash
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.