This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: canonicalize_condition vs zero_extract

> > * Check for a generic "this rtl has more than 2 xexp's"?
> This is better done...
> ... by simply checking for COMPARISON_P.

Patch attached.  OK to apply?  Tested by building the RX libraries and
seeing no ICEs.

> > * Find out why a zero_extract is getting this far in the first place?
> This also sounds like a good idea.  Maybe a small testcase and a 
> backtrace will be enough?

I haven't submitted that patch yet.  Basically, this code:

	if (a & 4) ...

with a target that uses TST insead of AND or CMP, gcc tries to make an
(if_then_else (zero_extract ...) ...) expression, which causes the

2010-07-02  DJ Delorie  <>

	* rtlanal.c (canonicalize_condition): Avoid non-comparison RTX.

Index: rtlanal.c
--- rtlanal.c	(revision 161744)
+++ rtlanal.c	(working copy)
@@ -4694,12 +4694,17 @@ canonicalize_condition (rtx insn, rtx co
   rtx tem;
   rtx op0, op1;
   int reverse_code = 0;
   enum machine_mode mode;
   basic_block bb = BLOCK_FOR_INSN (insn);
+  /* Single-bit tests sometimes use logic ops to generate the
+     condition, rather than comparisons.  */
+  if (! COMPARISON_P (cond))
+    return 0;
   code = GET_CODE (cond);
   mode = GET_MODE (cond);
   op0 = XEXP (cond, 0);
   op1 = XEXP (cond, 1);
   if (reverse)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]