This is the mail archive of the
mailing list for the GCC project.
Re: pa indirect_jump instruction
- From: Trevor Saunders <tbsaunde at tbsaunde dot org>
- To: gcc at gcc dot gnu dot org, law at redhat dot com, dave dot anglin at bell dot net, rdsandiford at googlemail dot com
- Date: Sun, 5 Jul 2015 05:06:57 -0400
- Subject: Re: pa indirect_jump instruction
- Authentication-results: sourceware.org; auth=none
- References: <87egks2a0k dot fsf at googlemail dot com> <20150701092835 dot GA11111 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <878uavaus4 dot fsf at googlemail dot com>
On Sun, Jul 05, 2015 at 09:11:23AM +0100, Richard Sandiford wrote:
> Trevor Saunders <firstname.lastname@example.org> writes:
> > On Tue, Jun 30, 2015 at 09:53:31PM +0100, Richard Sandiford wrote:
> >> I have a series of patches to convert all non-optab instructions to
> >> the target-insns.def interface. config-list.mk showed up one problem
> >> though. The pa indirect_jump pattern is:
> >> ;;; Hope this is only within a function...
> >> (define_insn "indirect_jump"
> >> [(set (pc) (match_operand 0 "register_operand" "r"))]
> >> "GET_MODE (operands) == word_mode"
> >> "bv%* %%r0(%0)"
> >> [(set_attr "type" "branch")
> >> (set_attr "length" "4")])
> >> so the C condition depends on operands, which isn't usually allowed
> >> for named patterns. We get away with it at the moment because we only
> >> test for the existence of HAVE_indirect_jump, not its value:
> > yeah, I hit this a while ago and filed bug 66114. It looks like I had
> > trouble with fr30 too, is that fixed now?
> Hmm, seems not. The fr30 build stopped earlier for me due to a warning
> turned error. I suppose I should really have fixed all the warnings shown
> by config-list.mk before doing this stuff...
yeah, that's certainly a problem worth working on, but there's certainly
something to be said for not going too far down the yak shaving rabbit