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: [email protected]
Reporter: [email protected]
CC: [email protected]
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.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
