Bug in FCOMI patch (fwd)

[H.J. Lu]

> 
> 
> HJ, there is a serious problem with your FCOMI patch.
> 
> Consider this code from notice_update_cc:
> 
>   else if (GET_CODE (exp) == PARALLEL
>            && GET_CODE (XVECEXP (exp, 0, 0)) == SET)
>     {
>       if (SET_DEST (XVECEXP (exp, 0, 0)) == pc_rtx)
>         return;
>       if (SET_DEST (XVECEXP (exp, 0, 0)) == cc0_rtx)
> 
>         {
>           CC_STATUS_INIT;
>           if (stack_regs_mentioned_p (SET_SRC (XVECEXP (exp, 0, 0))))
>             {
>               cc_status.flags |= CC_IN_80387;
>               if (TARGET_CMOVE && stack_regs_mentioned_p
>                   (XEXP (SET_SRC (XVECEXP (exp, 0, 0)), 1)))
>                 cc_status.flags |= CC_FCOMI;
>             }
>           else
>             cc_status.value1 = SET_SRC (XVECEXP (exp, 0, 0));
>           return;
>         }
> 
>       CC_STATUS_INIT;
>     }
> 
> 
> Precisely what kind of insn do you expect this code to be looking at?
> 
> One might guess it is supposed to look at conditional moves.  But the
> conditional move patterns do not reference cc0_rtx.
> 

I am not familiar with the code. Did you get confused by TARGET_CMOVE
here? It happened to me before.  I think what happens is TARGET_CMOVE
here is used to indicate the target CPU supports fcomi. Maybe we should
have a separate TARGET_FCOMI. Since cmove and fcomi were added to PPro
at the same time, I guess whoever wrote it just skipped TARGET_FCOMI.

> One might then guess it should be looking at test or compare instructions.
> 
> However, a floating point test looks like:
> 
> (define_insn "tstsf_cc"
>   [(set (cc0)
>         (match_operand:SF 0 "register_operand" "f"))
>    (clobber (match_scratch:HI 1 "=a"))]
> 
> XEXP (SET_SRC (XVECEXP (exp, 0, 0)), 1))  will reference a random hunk of
> memory  since a register_operand only has one operand.  In fact, we have a
> test where this is happening, which is causing the compiler to core dump.
> 

Could you please send me the testcase?

Thanks.

H.J.