[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support

["Paulo.Matos at csr dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782

--- Comment #2 from Paulo J. Matos <Paulo.Matos at csr dot com> 2011-02-17 14:56:45 UTC ---
Just a note to this... this bug assumes that cbranch<mode>4 is _not_
implemented. If cbranch<mode>4 is not an optional standard name to implement
then this bug is invalid, but we should document this requirement somewhere.

I just noticed that optabs.h has the comment before can_compare_p:

/* Nonzero if a compare of mode MODE can be done straightforwardly
   (without splitting it into pieces).  */
extern int can_compare_p (enum rtx_code, enum machine_mode,
              enum can_compare_purpose);

By this I assume that cbranch should be implemented if there is an instruction
that performs a compare and branch in one go without ''splitting it into
pieces''. However, by looking at the vax case (which I think it does not have
such an intruction) cbranch is implemented as:

(define_expand "cbranch<mode>4"
  [(set (cc0)
        (compare (match_operand:VAXint 1 "nonimmediate_operand" "")
                 (match_operand:VAXint 2 "general_operand" "")))
   (set (pc)
        (if_then_else
              (match_operator 0 "ordered_comparison_operator" [(cc0)
                                                               (const_int 0)])
              (label_ref (match_operand 3 "" ""))
              (pc)))]
 "")

which ends up expanding it into multiple insns...

I can do the same on my side. However, that makes cbranch non-optional which is
not-documented and breaks backward compatibility (in the sense that in previous
gcc versions the lack of a cbranch implementation didn't seem to trigger any
strange bug).