[LLVMbugs] [Bug 22831] New: Clang hit invalid cast assertion when calling a member function of an object not in the default address space

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=22831

            Bug ID: 22831
           Summary: Clang hit invalid cast assertion when calling a member
                    function of an object not in the default address space
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: interceptor2012 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13999
  --> http://llvm.org/bugs/attachment.cgi?id=13999&action=edit
Output from Clang, including the assertion hit and the stack trace.

Overview:

When compiling code that calls a member function of an object in a non-default
address space (e.g. address space 1), Clang hits an "invalid cast" assertion in
LLVM.

Steps to Reproduce:

See attached stack trace, preprocessed source, and run script.  I also tested
this issue using optimization level 0 and using the spir-unknown-unknown
target; the error occurs with these options as well.

Actual Results:

Clang hits an LLVM assertion.

Expected Results:

At the very least, Clang should produce a diagnostic for this code if the
operation is invalid (rather than falling through to an LLVM assert).  However,
I expect Clang should be able to generate valid code for this example. Since
this member function is not virtual, Clang should be able to resolve it at
compile time and simply pass a "this" pointer in the appropriate address space
to the function.  This behavior may differ if virtual functions are considered.

Build Date & Platform:

Tested on 03/05/2015 using Ubuntu 12.04 and LLVM and Clang trunk.

Additional Builds and Platforms:

N/A

Additional Information:

My intent is to generate SPIR code from C++ code similar to this minimal
example.  This code does not use virtual functions, so all function calls can
be resolved at compile time.  I believe that the address space in which an
object exists should not influence the ability to call member functions of that
object.  Thus, I should be able to have an object in the global address space
(address space 1 in SPIR) and still be able to call member functions, as long
as these functions can be resolved at compile time.  I am not certain how
virtual functions would impact this process.

-- 
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/20150307/9eea0fef/attachment.html>