[Bug target/21501] ICE in extract_insn, at recog.c:2082

["rearnsha at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From rearnsha at gcc dot gnu dot org  2005-05-11 09:36 -------
This compiles without problems for me with today's compiler:

$ /work/rearnsha/gnu/egcs/gcc/cc1 -O1 diff.c
 foo

Execution times (seconds)
 symout                :   0.00 ( 0%) usr   0.01 (100%) sys   0.01 (50%) wall
 TOTAL                 :   0.01             0.01             0.02
$ cat diff.s
        .file   "diff.c"
        .text
        .align  2
        .global foo
        .type   foo, %function
foo:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        @ lr needed for prologue
        mov     r3, #-67108864
        sub     r3, r3, #128
        add     r0, r0, r3
        bx      lr
        .size   foo, .-foo
        .ident  "GCC: (GNU) 4.1.0 20050511 (experimental)"

While developing the other patch that I committed at about the same time

2005-05-09  Richard Earnshaw  <richard.earnshaw@arm.com>

        * arm.c (const_ok_for_arm): Use a faster algorithm.

I did find that one of my machines (a netbsd-2.99 based machine with libraries
compiled for an ARMv5 core) had a buggy implementation of ffs(3).  If your
ffs(3) does not correctly determine the bottom bit in a constant, then the code
in const_ok_for_arm may well fail in the manner you describe.  That would be a
host bug, though.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


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