| Message ID | 55DC77AF.8060802@acm.org |
|---|---|
| State | New |
| Headers | show |
On 08/25/2015 08:11 AM, Nathan Sidwell wrote: > Ptx is one of those rare (unique?) machines that doesn't have an > indirect branch. optabs is prepared for such a target and emits a > sorry when an indirect branch is needed. However it then goes on to try > and emit such an instruction and ends up ICEing. > > Fixed thusly, ok? (Or is the right solution to define a dummy indirect > branch in the PTX md file?) I think we're trying to generally get away from dummy patterns. We could emulate by creating a new stack frame and shoving the target of the branch into the stack, then executing a return. However, I don't think that's worth doing ;-) I think the patch is fine for the trunk. jeff
On 08/25/15 15:10, Jeff Law wrote: > On 08/25/2015 08:11 AM, Nathan Sidwell wrote: > We could emulate by creating a new stack frame and shoving the target of the > branch into the stack, then executing a return. However, I don't think that's > worth doing ;-) And wouldn't work for PTX anyway -- all the return addr handling is hidden away. > I think the patch is fine for the trunk. ok.
2015-08-25 Nathan Sidwell <nathan@acm.org> * optabs (emit_indirect_jump): Don't try an emit a jump if the target doesn't have one. Index: gcc/optabs.c =================================================================== --- gcc/optabs.c (revision 227128) +++ gcc/optabs.c (working copy) @@ -4488,11 +4488,13 @@ emit_indirect_jump (rtx loc) { if (!targetm.have_indirect_jump ()) sorry ("indirect jumps are not available on this target"); - - struct expand_operand ops[1]; - create_address_operand (&ops[0], loc); - expand_jump_insn (targetm.code_for_indirect_jump, 1, ops); - emit_barrier (); + else + { + struct expand_operand ops[1]; + create_address_operand (&ops[0], loc); + expand_jump_insn (targetm.code_for_indirect_jump, 1, ops); + emit_barrier (); + } }