[llvm-bugs] [Bug 51890] New: [C++4OpenCL] Issues with address-spaced destructors

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51890

            Bug ID: 51890
           Summary: [C++4OpenCL] Issues with address-spaced destructors
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: OpenCL
          Assignee: unassignedclangbugs at nondot.org
          Reporter: olemarius.strohm at arm.com
                CC: anastasia.stulova at arm.com, llvm-bugs at lists.llvm.org

Here are some test cases that currently give an error in C++ for OpenCL, though
they should likely work.

Currently the simplest test case:
struct S {
    ~S() __global;
    ~S() __private;
};

void k() {
    __private S s;
}

Is incorrect because it uses the global destructor (It always uses the first
destructor that's defined.

This also extends to many other situations, like inheritance:

struct A {
    ~A() __global = delete;
    ~A() __private = default;
};

struct S: public A {
    ~S() __private;
};

void k() {
    __private S s;
}

Here trying to make a private variable fails because it thinks the destructor
of A is
deleted (because the first destructor is deleted), however if you reorder A's
destructors
it works, because it looks at the top one, which is not deleted.

Destructors are used in a lot of places, and address spaces aren't handled for
any of them,
so there are likely many more situations that are incorrect, but these are the
ones I've found specific cases for.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210917/d914f318/attachment.html>