GCC build failed with your patch on 2000-09-29T11:50:00Z.

Geoff Keating geoffk@cygnus.com
Sat Sep 30 17:10:00 GMT 2000

Jan Hubicka <jh@suse.cz> writes:

> > /sloth/delay/tbox/cvs-gcc/egcs/gcc/libgcc2.c: In function `__muldi3':
> > /sloth/delay/tbox/cvs-gcc/egcs/gcc/libgcc2.c:199: Internal compiler error in single_set_1, at rtlanal.c:881
> >    Please submit a full bug report.
> >    See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
> The problem seems to be caused by pattern:
>  [(match_parallel 0 "any_operand"
>                   [(clobber (match_operand:SI 1 "register_operand" "=l"))
> 		   (use (match_operand:SI 2 "call_operand" "s"))
> 		   (set (match_operand:DF 3 "memory_operand" "=m")
> 			(match_operand:DF 4 "gpc_reg_operand" "f"))])]
> That breaks the rule requiring the USEs and CLOBBERs to be last in the
> parallel.  Is there some elegant way to "fix" such pattern, or is this pattern
> good example why I should avoid this requirement at single_set_1?
> If so, I will send a patch shortly.  It increases the cost of single_set by
> factor of 3 on i386.

I looked at this and it's not just this pattern.

Examples of other patterns affected are:

(define_insn "return_eh_si"
  [(use (match_operand:SI 0 "register_operand" "lc"))
   (use (reg:SI 2))
   (use (reg:SI 3))]

(define_insn "*movsi_to_cr"
 [(match_parallel 0 "mtcrf_operation"
                  [(use (match_operand 1 "immediate_operand" "n"))
		   (set (match_operand:CC 2 "cc_reg_operand" "=y")
       			(unspec:CC [(match_operand:SI 3 "gpc_reg_operand" "r")
		   		    (match_operand 4 "immediate_operand" "n")]
 "mtcrf %1,%3")

(define_insn "*call_value_indirect_nonlocal_aix64"
  [(set (match_operand 0 "" "=fg")
	(call (mem:SI (match_operand:DI 1 "register_operand" "cl"))
	      (match_operand 2 "" "g")))
   (use (reg:DI 2))
   (use (reg:DI 11))
   (set (reg:DI 2)
	(mem:DI (plus:DI (reg:DI 1) (const_int 40))))
   (clobber (match_scratch:SI 3 "=l"))]
  "b%T1l\;ld 2,40(1)"
  [(set_attr "type" "jmpreg")
   (set_attr "length" "8")])

Now, I can fix these.  I am preparing a patch to fix some of them
(hopefully enough to be able to build again) now.  However, not all of
them would have been caught by the abort().  So I'm also going to send
in a patch that improves the abort() so that it scans through all of
the insn, and generates a warning instead.  This way we can determine
how bad the situation is.

- Geoffrey Keating <geoffk@cygnus.com>

More information about the Gcc mailing list