[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