[LLVMbugs] [Bug 21058] New: ParseAssemblyString does not resolve types already present in module

[bugzilla-daemon at llvm.org]

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

            Bug ID: 21058
           Summary: ParseAssemblyString does not resolve types already
                    present in module
           Product: libraries
           Version: trunk
          Hardware: Macintosh
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM assembly language parser
          Assignee: unassignedbugs at nondot.org
          Reporter: jan+llvm-bugzilla at sheijk.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13085
  --> http://llvm.org/bugs/attachment.cgi?id=13085&action=edit
Repro case

Reproduction steps:

- create a new LLVM module
- define a new named struct type foo_t (either using 
- call ParseAssemblyString passing it the existing module and a source string
that uses one of the types added before

Or compile the attached file and run it w/o arguments to use
ParseAssemblyString to define the type or with --api-type to create foo_t using
the C++ API.

Expected:

Functions in the textural LLVM IR passed to ParseAssemblyString will use the
type struct.foo_t which is already defined in the module.

What happens:

Whenever this new code references struct.foo_t the parser creates a new opaque
struct type struct.foo_t.0 and uses that instead of struct.foo_t. This looks
like the same behaviour as when creating a new struct type with a name that is
already used.

The parser in lib/AsmParser/LLParser.cpp seems to look up named structs in it's
member NamedTypes in function ParseType. NamedTypes gets polulated when new
types get defined in ParseNamedType but I don't see it getting filled with the
existing types of the module. So ParseType will create a new opaque type that
gets renamed due to the naming conflict. I think this could easily be solved by
looking up the named type in the module (LLParser::M) inside ParseType using
Module::getTypeByName.

-- 
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/20140924/044ac20c/attachment.html>