diff options
| author | Bill Wendling <isanbard@gmail.com> | 2011-04-11 21:32:34 +0000 |
|---|---|---|
| committer | Bill Wendling <isanbard@gmail.com> | 2011-04-11 21:32:34 +0000 |
| commit | 1e1f1c9ce10ffc8b0d5d9d038c26bda8f613af2c (patch) | |
| tree | 623906100ed199ec9b7cefecf120f808883e6f8e /llvm/lib/Target/MBlaze/Disassembler/MBlazeDisassembler.cpp | |
| parent | 1248df43bf467d702c62d0d9bd34a1b9b349e6c6 (diff) | |
| download | bcm5719-llvm-1e1f1c9ce10ffc8b0d5d9d038c26bda8f613af2c.tar.gz bcm5719-llvm-1e1f1c9ce10ffc8b0d5d9d038c26bda8f613af2c.zip | |
The default of the dispatch switch statement was to branch to a BB that executed
the 'unwind' instruction. However, later on that instruction was converted into
a jump to the basic block it was located in, causing an infinite loop when we
get there.
It turns out, we get there if the _Unwind_Resume_or_Rethrow call returns (which
it's not supposed to do). It returns if it cannot find a place to unwind
to. Thus we would get what appears to be a "hang" when in reality it's just that
the EH couldn't be propagated further along.
Instead of infinitely looping (or calling `unwind', which none of our back-ends
support (it's lowered into nothing...)), call the @llvm.trap() intrinsic
instead. This may not conform to specific rules of a particular language, but
it's rather better than infinitely looping.
<rdar://problem/9175843&9233582>
llvm-svn: 129302
Diffstat (limited to 'llvm/lib/Target/MBlaze/Disassembler/MBlazeDisassembler.cpp')
0 files changed, 0 insertions, 0 deletions
