[llvm-dev] Assertion fail/crash in X86FrameLowering::GetFrameIndexReference SEH

[Reid Kleckner via llvm-dev]

Should be fixed in r284612

On Wed, Oct 19, 2016 at 10:00 AM, Reid Kleckner <rnk at google.com> wrote:

> I think r262546 introduced the assumption that allocas are used exactly
> once with catchpad. It seems easy to fix, though.
>
> On Mon, Oct 17, 2016 at 11:51 PM, Carlo Kok via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> This turned out to be related to reusing the local used in the catchpad,
>> for example given the following c++ code:
>>
>> extern void rthrow();
>>
>> int main() {
>>     try
>>     {
>>         try {
>>             rthrow();
>>         } catch(int* v) {
>>             rthrow();
>>         }
>>     } catch (int* v)
>>     {
>>         rthrow();
>>     }
>>     return 0;
>> }
>>
>> Generates two:
>>
>>   %7 = catchpad within %5 [%rtti.TypeDescriptor4* @"\01??_R0PAH at 8", i32
>> 0, i32** %2]
>>   %11 = catchpad within %9 [%rtti.TypeDescriptor4* @"\01??_R0PAH at 8", i32
>> 0, i32** %3]
>>
>> If I change either of them to have the %2 in both, it crashes llvm.
>>
>>
>> On 2016-10-17 18:02, Carlo Kok via llvm-dev wrote:
>>
>>> Hi,
>>>
>>> I'm gettign an assertion fail/crash in
>>> X86FrameLowering::GetFrameIndexReference when compiling the following
>>> bitcode:
>>>
>>> https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0480b0
>>>
>>> I tried removing the llvm.frameaddres calls but that's not it, where can
>>> I start looking for what my mistake here is? Code seems to verify just
>>> fine.
>>>
>>>
>>> ; #0 0x00e1afe8 llvm::X86FrameLowering::getFrameIndexReference(class
>>> llvm::MachineFunction const &,int,unsigned int &)const
>>> c:\p\llvm\llvm\lib\target\x86\x86framelowering.cpp:1672:0
>>> ; #1 0x00f99010 llvm::WinException::getFrameIndexOffset(int,struct
>>> llvm::WinEHFuncInfo const &)
>>> c:\p\llvm\llvm\lib\codegen\asmprinter\winexception.cpp:320:0
>>> ; #2 0x00f97f75 llvm::WinException::emitCXXFrameHandler3Table(class
>>> llvm::MachineFunction const *,bool)
>>> c:\p\llvm\llvm\lib\codegen\asmprinter\winexception.cpp:805:0
>>> ; #3 0x00f98e77 llvm::WinException::endFunction(class
>>> llvm::MachineFunction const *)
>>> c:\p\llvm\llvm\lib\codegen\asmprinter\winexception.cpp:146:0
>>> ; #4 0x00f685f7 llvm::AsmPrinter::EmitFunctionBody(void)
>>> c:\p\llvm\llvm\lib\codegen\asmprinter\asmprinter.cpp:978:0
>>> ; #5 0x00d307fa llvm::X86AsmPrinter::runOnMachineFunction(class
>>> llvm::MachineFunction &)
>>> c:\p\llvm\llvm\lib\target\x86\x86asmprinter.cpp:73:0
>>> ; #6 0x01021d1b llvm::MachineFunctionPass::runOnFunction(class
>>> llvm::Function &) c:\p\llvm\llvm\lib\codegen\mac
>>> hinefunctionpass.cpp:64:0
>>> ; #7 0x011a8f40 llvm::FPPassManager::runOnFunction(class llvm::Function
>>> &) c:\p\llvm\llvm\lib\ir\legacypassmanager.cpp:1522:0
>>> ; #8 0x011a9083 llvm::FPPassManager::runOnModule(class llvm::Module &)
>>> c:\p\llvm\llvm\lib\ir\legacypassmanager.cpp:1542:0
>>> ; #9 0x011a9202 `anonymous namespace'::MPPassManager::runOnModule
>>> c:\p\llvm\llvm\lib\ir\legacypassmanager.cpp:1599:0
>>> ; #10 0x011a8b49 llvm::legacy::PassManagerImpl::run(class llvm::Module
>>> &) c:\p\llvm\llvm\lib\ir\legacypassmanager.cpp:1703:0
>>> ; #11 0x00aee750 compileModule c:\p\llvm\llvm\tools\llc\llc.cpp:508:0
>>> ; #12 0x00af2e2a main c:\p\llvm\llvm\tools\llc\llc.cpp:273:0
>>> ; #13 0x015b7e28 _scrt_common_main_seh
>>> f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253:0
>>> ; #14 0x769e62c4 (C:\WINDOWS\System32\KERNEL32.DLL+0x162c4)
>>> ; #15 0x772f0609 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x60609)
>>> ; #16 0x772f05d4 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x605d4)
>>>
>>>
>>> bitcode: https://gist.github.com/carlokok/868cddebeb9acc8ccbac6253de0
>>> 480b0
>>>
>>>
>> --
>> Carlo Kok
>> RemObjects Software
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/b767beab/attachment.html>