[LLVMbugs] [Bug 15529] New: DISubprogram treats return type in inconsistent way causing assertion failure in Verify

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Mar 16 07:01:37 PDT 2013


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

            Bug ID: 15529
           Summary: DISubprogram treats return type in inconsistent way
                    causing assertion failure in Verify
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
          Assignee: unassignedbugs at nondot.org
          Reporter: kai at redstar.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I try to create debug info for a function which returns an int.

The return type is created via DIBuilder->createBasicType() and the returned
object is passed to DIBuilder->createFunction() as the return type.
I get an assertion failure if I call DISubprogram->Verify() on such constructed
object.

According to the DWARF 3/4 spec my approach is legal. The right value is
returned by DISubprogram->getReturnTypeName() because it is implemented as the
comment specifies:

    /// getReturnTypeName - Subprogram return types are encoded either as
    /// DIType or as DICompositeType.

But:
- DISubprogram->Verify() fails because it always expects a DICompositeType
- You can't retrieve the return type if it is different from DICompositeType
because DISubprogram->getType() always returns a DICompositeType.

Resolution would be:
(a) always require a DICompositeType for the return type OR
(b) implement getType() and Verify() analog to getReturnTypeName()

-- 
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/20130316/62689787/attachment.html>


More information about the llvm-bugs mailing list