Skip to content
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

Closed
llvmbot opened this issue Jan 24, 2010 · 2 comments
Labels
bugzilla Issues migrated from bugzilla clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@llvmbot
Copy link
Member

llvmbot commented Jan 24, 2010

Bugzilla Link 6131
Resolution FIXED
Resolved on Sep 02, 2010 07:56
Version trunk
OS Linux
Attachments Testcase to demonstrate the problem, backtrace for the clang crash
Reporter LLVM Bugzilla Contributor
CC @davidchisnall

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

@davidchisnall
Copy link
Contributor

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?)

@davidchisnall
Copy link
Contributor

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.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
kovdan01 added a commit to kovdan01/llvm-project that referenced this issue Sep 18, 2024
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>
kovdan01 added a commit that referenced this issue Sep 19, 2024
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>
tmsri pushed a commit to tmsri/llvm-project that referenced this issue Sep 19, 2024
…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>
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
Development

No branches or pull requests

2 participants