opt -verify

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

opt -verify

Ryan M. Lefever
I am writing an interprocedural compiler pass.  Because the passneeds
information from a FunctionPass, e.g., the post-dominance frontier
(PDF), and because a ModulePass is not permitted to require a
FunctionPass, I am forced to make my pass a FunctionPass and do majority
of its work in the doFinalization() method.

When I run "opt -mypass -verify -o code2.bc code1.bc" I get no
complaints.  However, if I then try run "opt -simplifycfg -verify -o
code3.bc code2.bc," I get the assertion failure below.  If thought that
the verify option should have made sure that bytecode written to
code2.bc was correct.  Am I incorrect?

opt: Reader.cpp:1978: llvm::Value*
llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion
`(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) ||
!hasImplicitNull(TypeID) && "Cannot read null values from bytecode!"'
failed.
opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
[0x70f420]
/lib/libc.so.6(abort+0x101)[0x4cab64f1]
/lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
int)+0x1b31)[0x856e825]
opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
std::allocator<llvm::BytecodeReader::ValueList*> >&,
std::vector<llvm::PATypeHolder, std::allocator<llvm::PATypeHolder> >&,
bool)+0x147)[0x856e985]
opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*, unsigned
int, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
opt((anonymous
namespace)::BytecodeFileReader::read(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >*,
llvm::BytecodeHandler*)+0x93)[0x855b60b]
opt(llvm::ParseBytecodeFile(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::basic_string<char, std::char_traits<char>, std::allocator<char>
 >*)+0x20)[0x855b88e]
opt(main+0x7e)[0x8378c90]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
opt(__gxx_personality_v0+0x149)[0x836bac1]
Abort

Regards,
Ryan


--
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: opt -verify

Chris Lattner
On Wed, 21 Feb 2007, Ryan M. Lefever wrote:
> I am writing an interprocedural compiler pass.  Because the passneeds
> information from a FunctionPass, e.g., the post-dominance frontier
> (PDF), and because a ModulePass is not permitted to require a
> FunctionPass, I am forced to make my pass a FunctionPass and do majority
> of its work in the doFinalization() method.

ok

> When I run "opt -mypass -verify -o code2.bc code1.bc" I get no
> complaints.  However, if I then try run "opt -simplifycfg -verify -o
> code3.bc code2.bc," I get the assertion failure below.  If thought that
> the verify option should have made sure that bytecode written to
> code2.bc was correct.  Am I incorrect?

Yes.  the passmanager runs the passes in roughly this order:

1. doinitialization for mypass and verify
2. runOnModule for mypass
3. verifier::runOnFunction for each function
4. dofinalization for mypass
5. dofinalization for verify

Because you'd doing your xform in #4, but verifier checks the code at #3,
you lose :(

However, there is hope!  Just call "llvm/Analysis/Verifier.h" ->
verifyModule or verifyFunction explicitly in your pass.

-Chris

> opt: Reader.cpp:1978: llvm::Value*
> llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion
> `(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) ||
> !hasImplicitNull(TypeID) && "Cannot read null values from bytecode!"'
> failed.
> opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
> opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
> [0x70f420]
> /lib/libc.so.6(abort+0x101)[0x4cab64f1]
> /lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
> opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
> int)+0x1b31)[0x856e825]
> opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
> std::allocator<llvm::BytecodeReader::ValueList*> >&,
> std::vector<llvm::PATypeHolder, std::allocator<llvm::PATypeHolder> >&,
> bool)+0x147)[0x856e985]
> opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
> opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*, unsigned
> int, std::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const&, std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
> opt((anonymous
> namespace)::BytecodeFileReader::read(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
> opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >*,
> llvm::BytecodeHandler*)+0x93)[0x855b60b]
> opt(llvm::ParseBytecodeFile(std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> std::basic_string<char, std::char_traits<char>, std::allocator<char>
> >*)+0x20)[0x855b88e]
> opt(main+0x7e)[0x8378c90]
> /lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
> opt(__gxx_personality_v0+0x149)[0x836bac1]
> Abort
>
> Regards,
> Ryan
>
>
>

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: opt -verify

Ryan M. Lefever
I followed what you said and called verifyModule() with the
AbortProcessAction option.  verifyModule() returns false, but does not
abort and does not print out any information about what caused the
verification to fail.

Chris Lattner wrote:

> On Wed, 21 Feb 2007, Ryan M. Lefever wrote:
>> I am writing an interprocedural compiler pass.  Because the passneeds
>> information from a FunctionPass, e.g., the post-dominance frontier
>> (PDF), and because a ModulePass is not permitted to require a
>> FunctionPass, I am forced to make my pass a FunctionPass and do majority
>> of its work in the doFinalization() method.
>
> ok
>
>> When I run "opt -mypass -verify -o code2.bc code1.bc" I get no
>> complaints.  However, if I then try run "opt -simplifycfg -verify -o
>> code3.bc code2.bc," I get the assertion failure below.  If thought that
>> the verify option should have made sure that bytecode written to
>> code2.bc was correct.  Am I incorrect?
>
> Yes.  the passmanager runs the passes in roughly this order:
>
> 1. doinitialization for mypass and verify
> 2. runOnModule for mypass
> 3. verifier::runOnFunction for each function
> 4. dofinalization for mypass
> 5. dofinalization for verify
>
> Because you'd doing your xform in #4, but verifier checks the code at #3,
> you lose :(
>
> However, there is hope!  Just call "llvm/Analysis/Verifier.h" ->
> verifyModule or verifyFunction explicitly in your pass.
>
> -Chris
>
>> opt: Reader.cpp:1978: llvm::Value*
>> llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion
>> `(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) ||
>> !hasImplicitNull(TypeID) && "Cannot read null values from bytecode!"'
>> failed.
>> opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
>> opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
>> [0x70f420]
>> /lib/libc.so.6(abort+0x101)[0x4cab64f1]
>> /lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
>> opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
>> int)+0x1b31)[0x856e825]
>> opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
>> std::allocator<llvm::BytecodeReader::ValueList*> >&,
>> std::vector<llvm::PATypeHolder, std::allocator<llvm::PATypeHolder> >&,
>> bool)+0x147)[0x856e985]
>> opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
>> opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*, unsigned
>> int, std::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const&, std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
>> opt((anonymous
>> namespace)::BytecodeFileReader::read(std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
>> opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&,
>> std::basic_string<char, std::char_traits<char>, std::allocator<char> >*,
>> llvm::BytecodeHandler*)+0x93)[0x855b60b]
>> opt(llvm::ParseBytecodeFile(std::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&,
>> std::basic_string<char, std::char_traits<char>, std::allocator<char>
>>> *)+0x20)[0x855b88e]
>> opt(main+0x7e)[0x8378c90]
>> /lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
>> opt(__gxx_personality_v0+0x149)[0x836bac1]
>> Abort
>>
>> Regards,
>> Ryan
>>
>>
>>
>
> -Chris
>

--
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: opt -verify

Ryan M. Lefever
I also tried iterating through the functions of the module and calling
verifyFunction(), which also returns false, but does not cause an abort
or report anything to stderr about what caused the verification to fail.
  From the doxygen for verifyFunction() and verifyModule(), it seems
like they both should print information to stderr if the verification
fails and should abort opt if AbortProcessAction is passed as parameter.
  Is this a bug?

Ryan M. Lefever wrote:

> I followed what you said and called verifyModule() with the
> AbortProcessAction option.  verifyModule() returns false, but does not
> abort and does not print out any information about what caused the
> verification to fail.
>
> Chris Lattner wrote:
>
>>On Wed, 21 Feb 2007, Ryan M. Lefever wrote:
>>
>>>I am writing an interprocedural compiler pass.  Because the passneeds
>>>information from a FunctionPass, e.g., the post-dominance frontier
>>>(PDF), and because a ModulePass is not permitted to require a
>>>FunctionPass, I am forced to make my pass a FunctionPass and do majority
>>>of its work in the doFinalization() method.
>>
>>ok
>>
>>
>>>When I run "opt -mypass -verify -o code2.bc code1.bc" I get no
>>>complaints.  However, if I then try run "opt -simplifycfg -verify -o
>>>code3.bc code2.bc," I get the assertion failure below.  If thought that
>>>the verify option should have made sure that bytecode written to
>>>code2.bc was correct.  Am I incorrect?
>>
>>Yes.  the passmanager runs the passes in roughly this order:
>>
>>1. doinitialization for mypass and verify
>>2. runOnModule for mypass
>>3. verifier::runOnFunction for each function
>>4. dofinalization for mypass
>>5. dofinalization for verify
>>
>>Because you'd doing your xform in #4, but verifier checks the code at #3,
>>you lose :(
>>
>>However, there is hope!  Just call "llvm/Analysis/Verifier.h" ->
>>verifyModule or verifyFunction explicitly in your pass.
>>
>>-Chris
>>
>>
>>>opt: Reader.cpp:1978: llvm::Value*
>>>llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion
>>>`(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) ||
>>>!hasImplicitNull(TypeID) && "Cannot read null values from bytecode!"'
>>>failed.
>>>opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
>>>opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
>>>[0x70f420]
>>>/lib/libc.so.6(abort+0x101)[0x4cab64f1]
>>>/lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
>>>opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
>>>int)+0x1b31)[0x856e825]
>>>opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
>>>std::allocator<llvm::BytecodeReader::ValueList*> >&,
>>>std::vector<llvm::PATypeHolder, std::allocator<llvm::PATypeHolder> >&,
>>>bool)+0x147)[0x856e985]
>>>opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
>>>opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*, unsigned
>>>int, std::basic_string<char, std::char_traits<char>,
>>>std::allocator<char> > const&, std::basic_string<char,
>>>std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
>>>opt((anonymous
>>>namespace)::BytecodeFileReader::read(std::basic_string<char,
>>>std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
>>>opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
>>>std::char_traits<char>, std::allocator<char> > const&,
>>>std::basic_string<char, std::char_traits<char>, std::allocator<char> >*,
>>>llvm::BytecodeHandler*)+0x93)[0x855b60b]
>>>opt(llvm::ParseBytecodeFile(std::basic_string<char,
>>>std::char_traits<char>, std::allocator<char> > const&,
>>>std::basic_string<char, std::char_traits<char>, std::allocator<char>
>>>
>>>>*)+0x20)[0x855b88e]
>>>
>>>opt(main+0x7e)[0x8378c90]
>>>/lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
>>>opt(__gxx_personality_v0+0x149)[0x836bac1]
>>>Abort
>>>
>>>Regards,
>>>Ryan
>>>
>>>
>>>
>>
>>-Chris
>>
>
>

--
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: opt -verify

Ryan M. Lefever
I think I misread the doxygen.  verifyFunction & verifyModule return
false if no errors are detected.  However, my question now becomes why
does the code produced by my transform pass verification, but it causes
an assertion failure in the byte reader when it (the code produced by my
transform) is passed to another invocation of opt?

Ryan M. Lefever wrote:

> I also tried iterating through the functions of the module and calling
> verifyFunction(), which also returns false, but does not cause an abort
> or report anything to stderr about what caused the verification to fail.
>   From the doxygen for verifyFunction() and verifyModule(), it seems
> like they both should print information to stderr if the verification
> fails and should abort opt if AbortProcessAction is passed as parameter.
>   Is this a bug?
>
> Ryan M. Lefever wrote:
>
>>I followed what you said and called verifyModule() with the
>>AbortProcessAction option.  verifyModule() returns false, but does not
>>abort and does not print out any information about what caused the
>>verification to fail.
>>
>>Chris Lattner wrote:
>>
>>
>>>On Wed, 21 Feb 2007, Ryan M. Lefever wrote:
>>>
>>>
>>>>I am writing an interprocedural compiler pass.  Because the passneeds
>>>>information from a FunctionPass, e.g., the post-dominance frontier
>>>>(PDF), and because a ModulePass is not permitted to require a
>>>>FunctionPass, I am forced to make my pass a FunctionPass and do majority
>>>>of its work in the doFinalization() method.
>>>
>>>ok
>>>
>>>
>>>
>>>>When I run "opt -mypass -verify -o code2.bc code1.bc" I get no
>>>>complaints.  However, if I then try run "opt -simplifycfg -verify -o
>>>>code3.bc code2.bc," I get the assertion failure below.  If thought that
>>>>the verify option should have made sure that bytecode written to
>>>>code2.bc was correct.  Am I incorrect?
>>>
>>>Yes.  the passmanager runs the passes in roughly this order:
>>>
>>>1. doinitialization for mypass and verify
>>>2. runOnModule for mypass
>>>3. verifier::runOnFunction for each function
>>>4. dofinalization for mypass
>>>5. dofinalization for verify
>>>
>>>Because you'd doing your xform in #4, but verifier checks the code at #3,
>>>you lose :(
>>>
>>>However, there is hope!  Just call "llvm/Analysis/Verifier.h" ->
>>>verifyModule or verifyFunction explicitly in your pass.
>>>
>>>-Chris
>>>
>>>
>>>
>>>>opt: Reader.cpp:1978: llvm::Value*
>>>>llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion
>>>>`(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) ||
>>>>!hasImplicitNull(TypeID) && "Cannot read null values from bytecode!"'
>>>>failed.
>>>>opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
>>>>opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
>>>>[0x70f420]
>>>>/lib/libc.so.6(abort+0x101)[0x4cab64f1]
>>>>/lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
>>>>opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
>>>>int)+0x1b31)[0x856e825]
>>>>opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
>>>>std::allocator<llvm::BytecodeReader::ValueList*> >&,
>>>>std::vector<llvm::PATypeHolder, std::allocator<llvm::PATypeHolder> >&,
>>>>bool)+0x147)[0x856e985]
>>>>opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
>>>>opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*, unsigned
>>>>int, std::basic_string<char, std::char_traits<char>,
>>>>std::allocator<char> > const&, std::basic_string<char,
>>>>std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
>>>>opt((anonymous
>>>>namespace)::BytecodeFileReader::read(std::basic_string<char,
>>>>std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
>>>>opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
>>>>std::char_traits<char>, std::allocator<char> > const&,
>>>>std::basic_string<char, std::char_traits<char>, std::allocator<char> >*,
>>>>llvm::BytecodeHandler*)+0x93)[0x855b60b]
>>>>opt(llvm::ParseBytecodeFile(std::basic_string<char,
>>>>std::char_traits<char>, std::allocator<char> > const&,
>>>>std::basic_string<char, std::char_traits<char>, std::allocator<char>
>>>>
>>>>>*)+0x20)[0x855b88e]
>>>>
>>>>opt(main+0x7e)[0x8378c90]
>>>>/lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
>>>>opt(__gxx_personality_v0+0x149)[0x836bac1]
>>>>Abort
>>>>
>>>>Regards,
>>>>Ryan
>>>>
>>>>
>>>>
>>>
>>>-Chris
>>>
>>
>>
>

--
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: opt -verify

Devang Patel
In reply to this post by Ryan M. Lefever

On Feb 22, 2007, at 2:17 PM, Ryan M. Lefever wrote:

> I also tried iterating through the functions of the module and calling
> verifyFunction(), which also returns false, but does not cause an  
> abort
> or report anything to stderr about what caused the verification to  
> fail.

If verifyFunction() return false then it means  it is not broken. I  
think you want
to use verifyModule() for your case.

-
Devang


>   From the doxygen for verifyFunction() and verifyModule(), it seems
> like they both should print information to stderr if the verification
> fails and should abort opt if AbortProcessAction is passed as  
> parameter.
>   Is this a bug?
>
> Ryan M. Lefever wrote:
>> I followed what you said and called verifyModule() with the
>> AbortProcessAction option.  verifyModule() returns false, but does  
>> not
>> abort and does not print out any information about what caused the
>> verification to fail.
>>
>> Chris Lattner wrote:
>>
>>> On Wed, 21 Feb 2007, Ryan M. Lefever wrote:
>>>
>>>> I am writing an interprocedural compiler pass.  Because the  
>>>> passneeds
>>>> information from a FunctionPass, e.g., the post-dominance frontier
>>>> (PDF), and because a ModulePass is not permitted to require a
>>>> FunctionPass, I am forced to make my pass a FunctionPass and do  
>>>> majority
>>>> of its work in the doFinalization() method.
>>>
>>> ok
>>>
>>>
>>>> When I run "opt -mypass -verify -o code2.bc code1.bc" I get no
>>>> complaints.  However, if I then try run "opt -simplifycfg -verify  
>>>> -o
>>>> code3.bc code2.bc," I get the assertion failure below.  If  
>>>> thought that
>>>> the verify option should have made sure that bytecode written to
>>>> code2.bc was correct.  Am I incorrect?
>>>
>>> Yes.  the passmanager runs the passes in roughly this order:
>>>
>>> 1. doinitialization for mypass and verify
>>> 2. runOnModule for mypass
>>> 3. verifier::runOnFunction for each function
>>> 4. dofinalization for mypass
>>> 5. dofinalization for verify
>>>
>>> Because you'd doing your xform in #4, but verifier checks the code  
>>> at #3,
>>> you lose :(
>>>
>>> However, there is hope!  Just call "llvm/Analysis/Verifier.h" ->
>>> verifyModule or verifyFunction explicitly in your pass.
>>>
>>> -Chris
>>>
>>>
>>>> opt: Reader.cpp:1978: llvm::Value*
>>>> llvm::BytecodeReader::ParseConstantPoolValue(unsigned int):  
>>>> Assertion
>>>> `(!isa<Constant>(Result) || !cast<Constant>(Result)-
>>>> >isNullValue()) ||
>>>> !hasImplicitNull(TypeID) && "Cannot read null values from  
>>>> bytecode!"'
>>>> failed.
>>>> opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
>>>> opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
>>>> [0x70f420]
>>>> /lib/libc.so.6(abort+0x101)[0x4cab64f1]
>>>> /lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
>>>> opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
>>>> int)+0x1b31)[0x856e825]
>>>> opt
>>>> (llvm
>>>> ::BytecodeReader
>>>> ::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
>>>> std::allocator<llvm::BytecodeReader::ValueList*> >&,
>>>> std::vector<llvm::PATypeHolder,  
>>>> std::allocator<llvm::PATypeHolder> >&,
>>>> bool)+0x147)[0x856e985]
>>>> opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
>>>> opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*,  
>>>> unsigned
>>>> int, std::basic_string<char, std::char_traits<char>,
>>>> std::allocator<char> > const&, std::basic_string<char,
>>>> std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
>>>> opt((anonymous
>>>> namespace)::BytecodeFileReader::read(std::basic_string<char,
>>>> std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
>>>> opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
>>>> std::char_traits<char>, std::allocator<char> > const&,
>>>> std::basic_string<char, std::char_traits<char>,  
>>>> std::allocator<char> >*,
>>>> llvm::BytecodeHandler*)+0x93)[0x855b60b]
>>>> opt(llvm::ParseBytecodeFile(std::basic_string<char,
>>>> std::char_traits<char>, std::allocator<char> > const&,
>>>> std::basic_string<char, std::char_traits<char>,  
>>>> std::allocator<char>
>>>>
>>>>> *)+0x20)[0x855b88e]
>>>>
>>>> opt(main+0x7e)[0x8378c90]
>>>> /lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
>>>> opt(__gxx_personality_v0+0x149)[0x836bac1]
>>>> Abort
>>>>
>>>> Regards,
>>>> Ryan
>>>>
>>>>
>>>>
>>>
>>> -Chris
>>>
>>
>>
>
> --
> Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: opt -verify

Reid Spencer-2
In reply to this post by Ryan M. Lefever
Ryan,


On Thu, 22 Feb 2007 16:26:24 -0600
  "Ryan M. Lefever" <[hidden email]> wrote:
> I think I misread the doxygen.  verifyFunction &
>verifyModule return
> false if no errors are detected.  However, my question
>now becomes why
> does the code produced by my transform pass
>verification, but it causes
> an assertion failure in the byte reader when it (the
>code produced by my
> transform) is passed to another invocation of opt?

There's only two explanations for that:

1. The verifier isn't catching something it should
2. There's a bug in the bytecode reader/writer.

Reid.

>
> Ryan M. Lefever wrote:
>> I also tried iterating through the functions of the
>>module and calling
>> verifyFunction(), which also returns false, but does not
>>cause an abort
>> or report anything to stderr about what caused the
>>verification to fail.
>>   From the doxygen for verifyFunction() and
>>verifyModule(), it seems
>> like they both should print information to stderr if the
>>verification
>> fails and should abort opt if AbortProcessAction is
>>passed as parameter.
>>   Is this a bug?
>>
>> Ryan M. Lefever wrote:
>>
>>>I followed what you said and called verifyModule() with
>>>the
>>>AbortProcessAction option.  verifyModule() returns false,
>>>but does not
>>>abort and does not print out any information about what
>>>caused the
>>>verification to fail.
>>>
>>>Chris Lattner wrote:
>>>
>>>
>>>>On Wed, 21 Feb 2007, Ryan M. Lefever wrote:
>>>>
>>>>
>>>>>I am writing an interprocedural compiler pass.  Because
>>>>>the passneeds
>>>>>information from a FunctionPass, e.g., the post-dominance
>>>>>frontier
>>>>>(PDF), and because a ModulePass is not permitted to
>>>>>require a
>>>>>FunctionPass, I am forced to make my pass a FunctionPass
>>>>>and do majority
>>>>>of its work in the doFinalization() method.
>>>>
>>>>ok
>>>>
>>>>
>>>>
>>>>>When I run "opt -mypass -verify -o code2.bc code1.bc" I
>>>>>get no
>>>>>complaints.  However, if I then try run "opt -simplifycfg
>>>>>-verify -o
>>>>>code3.bc code2.bc," I get the assertion failure below.
>>>>> If thought that
>>>>>the verify option should have made sure that bytecode
>>>>>written to
>>>>>code2.bc was correct.  Am I incorrect?
>>>>
>>>>Yes.  the passmanager runs the passes in roughly this
>>>>order:
>>>>
>>>>1. doinitialization for mypass and verify
>>>>2. runOnModule for mypass
>>>>3. verifier::runOnFunction for each function
>>>>4. dofinalization for mypass
>>>>5. dofinalization for verify
>>>>
>>>>Because you'd doing your xform in #4, but verifier checks
>>>>the code at #3,
>>>>you lose :(
>>>>
>>>>However, there is hope!  Just call
>>>>"llvm/Analysis/Verifier.h" ->
>>>>verifyModule or verifyFunction explicitly in your pass.
>>>>
>>>>-Chris
>>>>
>>>>
>>>>
>>>>>opt: Reader.cpp:1978: llvm::Value*
>>>>>llvm::BytecodeReader::ParseConstantPoolValue(unsigned
>>>>>int): Assertion
>>>>>`(!isa<Constant>(Result) ||
>>>>>!cast<Constant>(Result)->isNullValue()) ||
>>>>>!hasImplicitNull(TypeID) && "Cannot read null values from
>>>>>bytecode!"'
>>>>>failed.
>>>>>opt((anonymous
>>>>>namespace)::PrintStackTrace()+0x1a)[0x8645bae]
>>>>>opt((anonymous
>>>>>namespace)::SignalHandler(int)+0x112)[0x8645e74]
>>>>>[0x70f420]
>>>>>/lib/libc.so.6(abort+0x101)[0x4cab64f1]
>>>>>/lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
>>>>>opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
>>>>>int)+0x1b31)[0x856e825]
>>>>>opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
>>>>>std::allocator<llvm::BytecodeReader::ValueList*> >&,
>>>>>std::vector<llvm::PATypeHolder,
>>>>>std::allocator<llvm::PATypeHolder> >&,
>>>>>bool)+0x147)[0x856e985]
>>>>>opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
>>>>>opt(llvm::BytecodeReader::ParseBytecode(unsigned char
>>>>>const*, unsigned
>>>>>int, std::basic_string<char, std::char_traits<char>,
>>>>>std::allocator<char> > const&, std::basic_string<char,
>>>>>std::char_traits<char>, std::allocator<char>
>>>>>>*)+0x539)[0x856f6c1]
>>>>>opt((anonymous
>>>>>namespace)::BytecodeFileReader::read(std::basic_string<char,
>>>>>std::char_traits<char>, std::allocator<char>
>>>>>>*)+0xeb)[0x855b569]
>>>>>opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
>>>>>std::char_traits<char>, std::allocator<char> > const&,
>>>>>std::basic_string<char, std::char_traits<char>,
>>>>>std::allocator<char> >*,
>>>>>llvm::BytecodeHandler*)+0x93)[0x855b60b]
>>>>>opt(llvm::ParseBytecodeFile(std::basic_string<char,
>>>>>std::char_traits<char>, std::allocator<char> > const&,
>>>>>std::basic_string<char, std::char_traits<char>,
>>>>>std::allocator<char>
>>>>>
>>>>>>*)+0x20)[0x855b88e]
>>>>>
>>>>>opt(main+0x7e)[0x8378c90]
>>>>>/lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
>>>>>opt(__gxx_personality_v0+0x149)[0x836bac1]
>>>>>Abort
>>>>>
>>>>>Regards,
>>>>>Ryan
>>>>>
>>>>>
>>>>>
>>>>
>>>>-Chris
>>>>
>>>
>>>
>>
>
> --
> Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev