libtheora has a ICE when building under the Linaro toolchain

[Michael Hope]

Seen with gcc 4.4.4-6ubuntu5~ppa2 and libtheora 1.1.1+dfsg.1-3.

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -Wall -Wno-parentheses -O3 -fforce-addr -fomit-frame-pointer -finline-functions -funroll-loops -g -O2 -c mathops.c -fPIC -DPIC -o .libs/mathops.o
mathops.c: In function 'oc_blog64':
mathops.c:296: error: unable to generate reloads for:
(insn 758 609 770 12 mathops.c:288 (set (subreg:SI (reg:DI 2 r2 [648]) 0)
        (ior:SI (ashift:SI (reg:SI 6 r6 [688])
                (const_int -7 [0xfffffffffffffff9]))
            (subreg:SI (reg:DI 2 r2 [648]) 0))) 690 {*thumb2_arith_shiftsi} (nil))
mathops.c:296: internal compiler error: in find_reloads, at reload.c:3781

[Ulrich Weigand (uweigand)]

Confirmed; this seems to be a compiler bug.

Very much reduced test case:

long long
test (long long pat, long long mask)
{
  long long z = 0;
  int i;

  for (i = 39; i < 62; i++)
    z += (pat >> i) + mask ^ mask;

  return z;
}

If you build with cc1 test.i -march=armv7-a -mthumb -O2 you get with current Linaro GCC 4.4:

test.i:12: error: unable to generate reloads for:
(insn 79 86 81 2 test.i:9 (set (subreg:SI (reg:DI 4 r4 [140]) 0)
        (ior:SI (ashift:SI (reg:SI 1 r1 [orig:151 pat+4 ] [151])
                (const_int -7 [0xfffffffffffffff9]))
            (subreg:SI (reg:DI 4 r4 [140]) 0))) 689 {*thumb2_arith_shiftsi} (nil))
test.i:12: internal compiler error: in find_reloads, at reload.c:3781

This looks like a bug in the thumb2.md file:

(define_insn "*thumb2_arith_shiftsi"
  [(set (match_operand:SI 0 "s_register_operand" "=r")
        (match_operator:SI 1 "shiftable_operator"
          [(match_operator:SI 3 "shift_operator"
             [(match_operand:SI 4 "s_register_operand" "r")
              (match_operand:SI 5 "const_int_operand" "M")])
           (match_operand:SI 2 "s_register_operand" "r")]))]
  "TARGET_THUMB2"
  "%i1%?\\t%0, %2, %4%S3"
  [(set_attr "predicable" "yes")
   (set_attr "shift" "4")
   (set_attr "type" "alu_shift")]
)

Note how operand 5 claims to accept *any* immediate integer value in the predicate, but then offers just a single constraint "M" that accepts only a subset of immediate integer values? This implies any integer accepted by "const_int_operand" but then rejected by the "M" constraint will necessarily cause a reload failure. The pattern ought to either use a special predicate that matches what the constraint accepts, or else add appropriate tests to the overall insn condition.

[Michael Hope (michaelh1)]

fixed-in: 93542