bug report.

[Jim Wilson]

Gargoyle Crazy Master wrote:
> onlyjump_p (rtx insn)
>   set = single_set (insn);      <------------------ pc_set (insn)

It isn't clear why you are quoting this line from onlyjump_p.  What 
point are you trying to make here?  Are you assuming that the pattern of 
a jump must be a set because we call single_set here?  That isn't true. 
    The preferred form for a return insn is just a naked (return) in the 
pattern of a jump.

> redirect_exp_1 (rtx *loc, rtx olabel, rtx nlabel, rtx insn)
>       validate_change (insn, loc, gen_rtx_RETURN (VOIDmode), 1);

Again, it isn't clear what point you are trying to make here.

Why do you think this is wrong?  Did you get a gcc core dump?  Did you 
have some code miscompiled?  Did you have some code poorly optimized? 
Or something else?  Do you have a testcase?  It can be hard to comment 
on a suggestion like this if we don't know what you are trying to fix.

The difference between gen_rtx_RETURN and gen_return is that 
gen_rtx_RETURN will just return a naked (return), and gen_return will 
call the named "return" pattern in the md file.  For validate_change, 
calling a named pattern is very unlikely to be the right answer.  It 
looks like the code as written is correct, we want a naked return, and 
then we check to see if this is valid.

This may result in cases that are poorly optimized, because if a 
target's return pattern requires more than a naked (return), the 
validate_change call may fail, and we may leave the insn unoptimized. 
However, changing the validate_change call is wrong in that case.  If we 
want to get that case right, we would have to replace the insn with the 
output of gen_return.  Calling gen_return at this place would be wrong, 
because redirect_exp_1 can't replace the insn that is passed in to it. 
So getting this right may require a little structural change to the code.

Some of this is speculation because I don't have a testcase to look at. 
  Also, I need to know the target you are compiling for.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com