[LLVMdev] "Value in symtab but has no slot number!!"

[Reid Spencer]

Hi Ricardo,

On Fri, 2005-06-03 at 23:19 -0700, Ricardo wrote:
> Hi Reid,
> 
> Thanks for your help! I could detect the problem and the module now can be saved (it was a
> problem with some Alloca instructions). I could not find a "verify" method in the Module class,
> but just for the records, I did this:
> 
> ---------------
>   PassManager Passes;
>   // Add an appropriate TargetData instance for this module...
>   Passes.add(new TargetData("save", ModuleToSave));
>   // Make sure the input LLVM is well formed.
>   Passes.add(createVerifierPass());
>   Passes.run(*ModuleToSave);
> ---------------
> 

Perfect! :)

Or, just:

llvm::verifyModule(ModuleToSave);

:)

> I got stuck in another problem. I suppose it's very simple but I do not really know what is
> happening. I have a module like this:
> 
> ------------------------------------
> 	%binary_tree__0 = type { int, %binary_tree__0*, %binary_tree__0* }
> ...
> 
> 	%New__0 = alloca %binary_tree__0*		; <%binary_tree__0**> [#uses=8]
> 
> ...
> 	%Load_New__00 = load %binary_tree__0** %New__0		; <%binary_tree__0*> [#uses=0]
> 
> ...	
> 	%gep.1 = getelementptr %binary_tree__0* %Load_New__001, int 0, uint 0	; ...
> 
> ------------------------------------
> 
> Gives the error:
> 
> ---------------
> const llvm::Type* checkType(const llvm::Type*): Assertion `Ty && "Invalid indices for type!"'
> ---------------
> 
> However if I replace the last line for this:
> 
> ---------------
> 	%gep.1 = getelementptr %binary_tree__0* %Load_New__001, int 0, uint 1	; ...
> ---------------
> 
> Where the second index is 1 or 2, it works well. This means that I can obtain the second and third
> fields using getelementptr but not the first one! (which is an integer)

> Could you please help me?

Unfortunately, this has me a bit baffled too. I think however, that you
need some corrections to your code, or at least to be a little more
explicit with your example.   I note that you have 
%Load_New__00 of type %binary_tree_0** with 0 uses. However, you're
passing %Load_New__001 of type %binary_Tree__0* into getelementptr.
While the type of %Load_New_001 is correct for the indexing (two
arguments), %Load_New_00 would require three. Other than that, I don't
see why the two argument form with values 0,0 would cause an assertion
on this. It certainly looks correct to me.

Then again, getelementptr has always baffled me a bit :)

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050604/cc4a9df2/attachment.sig>