[llvm-bugs] [Bug 49191] New: [C++4OpenCL] Fix use of address spaces with new/delete

[via llvm-bugs]

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

            Bug ID: 49191
           Summary: [C++4OpenCL] Fix use of address spaces with new/delete
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: OpenCL
          Assignee: unassignedclangbugs at nondot.org
          Reporter: anastasia.stulova at arm.com
                CC: anastasia.stulova at arm.com, llvm-bugs at lists.llvm.org

The behavior of address spaces for new/delete is unclear i.e is it allowed to
use new/delete in named address spaces and in generic? It might be more helpful
to allow named address spaces since generic has not been intended for
allocations, but however generic makes things easier because it avoids
duplication and the concrete address space can always be cast to it. Use of
constant address space doesn't seem to make sense at all since nothing can be
done with a read-only chunk of memory?

Another aspect to consider - how will address spaces aligned with the concept
of overloading i.e.

    - Declaring multiple new operators with different address spaces in the
same scope generates an error since overloading by the return type is not
allowed.
    - Declaring multiple delete operators differing by address spaces seems to
fail because C++ doesn't allow to overload it yet.

Currently if other than generic address spaces are used clang fails with
various compile-time errors. For example, there is an error a new returning
pointer in a  local address space is assigned to local address space pointer
even if the declaration of new has the address space too:

`class A {
public:

__local void* operator new(size_t);

};
__local A* a = new A;`

error: assigning 'A *' to '__local A *' changes address space of pointer

-- 
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/20210215/c8c7730a/attachment.html>