llvm-dis < bytecode | llvm-as fails: "Reference to an invalid definition"

[llvmbot]

Bugzilla Link	370
Resolution	FIXED
Resolved on	Nov 07, 2018 00:17
Version	trunk
OS	All
Attachments	bytecode which fails
Reporter	LLVM Bugzilla Contributor

Extended Description

While working on the reoptimizer test framework I happened upon an llvm
bytecode file that I can't disassemble and reassemble successfully. I get the
following error:

216 kain> llvm-dis < lists.bc | llvm-as > sigh
llvm-as: :441: Reference to an invalid definition: #​6 of type ''

By the way, I don't think the error message type '' is correct.
I think it may be referencing the definition from main() marked below:

endif.8.i: ; preds = %endif.7.i
%tmp.2.i.i = load int* %tmp.83.i.i2099 ; [#uses=1]
cast %struct.DLL* %tmp.12.i.i.sub169 to sbyte* ; <sbyte*>:4 [#uses=1]
call void %free( sbyte* %4 )
cast %struct.DLL* %tmp.2.i.i.sub21101 to sbyte* ; <sbyte*>:5 [#uses=1]
call void %free( sbyte* %5 )
cast %struct.DLL* %1 to sbyte* ; <sbyte*>:6 [#uses=1] ** THIS ONE **
call void %free( sbyte* %6 )
br label %test_lists.entry

I will attach the bytecode to this bug.

[llvmbot]

I can't reproduce this Brian. Did you try it with a clean checkout of LLVM?

I get:

bash-2.05b$ llvm-dis < lists.bc | llvm-as > lists2.bc
bash-2.05b$

No error message.

Note that the "Reference to an invalid definition" message occurs only in
llvmAsmParser.y, only when resolving definitions (forward branches, phi
functions for loops, etc.). See llvmAsmParser.y:2079 for details. The message is
correct, its just that the value in question has a type with an empty
description (which is very odd).

Reid.

[llvmbot]

Note also that the basic block in question looks different in my build:

endif.8.i: ; preds = %endif.7.i
%tmp.2.i.i = load int* %tmp.83.i.i2099 ; [#uses=1]
cast %struct.DLL* %tmp.12.i.i.sub169 to sbyte* ; <sbyte*>:3 [#uses=1]
call void %free( sbyte* %3 )
cast %struct.DLL* %tmp.2.i.i.sub21101 to sbyte* ; <sbyte*>:4 [#uses=1]
call void %free( sbyte* %4 )
cast %struct.DLL* %0 to sbyte* ; <sbyte*>:5 [#uses=1]
call void %free( sbyte* %5 )
br label %test_lists.entry

Reid

[llvmbot]

Interesting...It doesn't seem to trigger the bug on powerpc. My sparc tree is clean
(except for a change to DIFFPROG in test/Programs/Makefile.programs), but it does
trigger there. I'm guessing that this is a sparc-only bug then.

It looks like it might be an off-by-one error somewhere, judging from the diffs
between the llvm-dis output on sparc and powerpc. I don't know much about
the asmparser code -- I'll post the llvm-dis outputs.

[llvmbot]

disassembly of testcase generated on the powerpc

[llvmbot]

disassembly of testcase generated on the sparc
This is the disassembly which fails. If you diff it against the powerpc one,
you see that a bunch of labels are off-by-one.

[llvmbot]

Brian,

I'm pretty sure that any small symbol table changes I made to llvmAsmParser.y
have not created this bug. I just reviewed my changes. However, its
possible. I'm willing to help with this, but as it only occurs on Sparc, I
have problems reproducing it. Do you think that you could alter the source to
reproduce on x86? If you can, I'll look into it.

Reid

[lattner]

I think this is probably a bug in the recent asmwriter changes. When running
llvm-dis under valgrind I get this:

==4566== Warning: attempt to set SIGKILL handler in __NR_sigaction.
==4566== Conditional jump or move depends on uninitialised value(s)
==4566== at 0x8182FF8: llvm::AssemblyWriter::printInfoComment(llvm::Value
const&) (AsmWriter.cpp:899)
==4566== by 0x8183D2B:
llvm::AssemblyWriter::printInstruction(llvm::Instruction const&)
(AsmWriter.cpp:1069)
==4566== by 0x8182F2C: llvm::AssemblyWriter::printBasicBlock(llvm::BasicBlock
const*) (AsmWriter.cpp:883)
==4566== by 0x8182B5A: llvm::AssemblyWriter::printFunction(llvm::Function
const*) (AsmWriter.cpp:819)
==4566== by 0x818232D: llvm::AssemblyWriter::printModule(llvm::Module const*)
(AsmWriter.cpp:697)
==4566== by 0x81AC94D: llvm::AssemblyWriter::write(llvm::Module const*)
(AsmWriter.cpp:585)
==4566== by 0x8183D97: llvm::Module::print(std::ostream&,
llvm::AssemblyAnnotationWriter*) const (AsmWriter.cpp:1081)
==4566== by 0x815CD7D: ??? (Module.h:221)

... which implies that getSlot is broken.

-Chris

[lattner]

Try this patch. It certainly fixes the valgrind issue, maybe it will fix the
problem you ran into as well:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040614/015222.html

If not, please reopen this bug.

-Chris

[llvmbot]

It looks like this solved it. Thanks!