bad assembler produced: Error: bit-field extends past end of register -- `ubfx r0,r0,#30,#10'

[Dr. David Alan Gilbert]

The attached example program, kindly generated by a colleague, fails with:

gcc -O3 arm_bit_extract.c
/tmp/ccOOK26S.s: Assembler messages:
/tmp/ccOOK26S.s:97: Error: bit-field extends past end of register -- `ubfx r0,r0,#30,#10'

The compiler is 4.5.2-8ubuntu1

It's questionable whether the results of the shifts done by the original program are actually defined,
but it shouldn't produce bad asm.

Dave

[Michael Hope (michaelh1)]

Thank you for the bug report. I've confirmed this with gcc-linaro-4.5-2011.04-0 on ARM:

michaelh@ursa1:~/linaro/bugs$ /tools/toolchains/arch/armv7l/gcc-linaro-4.5-2011.04-0-armv7l-maverick-cbuild112-ursa3-cortexa8r1/bin/gcc -O3 -c arm_bit_extract.c
/tmp/ccl0OX6a.s: Assembler messages:
/tmp/ccl0OX6a.s:97: Error: bit-field extends past end of register -- `ubfx r0,r0,#30,#10'

The assembler is correct - the instruction attempts to extract bits 30 to 39 from a 32 bit register.

The fault also exists in gcc-4.5.2. It does not exist in gcc-4.6.0. Could you please also report this in GCC bugzilla and attach it to this ticket?

I've set it to low priority as it is a ftbfs, occurs at high optimisation levels, the fault exists upstream, and the code uses undefined behavior by shifting by a negative amount.

[Chung-Lin Tang (cltang)]

Looking at the ARM backend patterns, I cannot rule out that 4.6 or upstream trunk is free of this bug. The current reason that it only shows in Linaro 4.5 (haven't checked FSF 4.5), is because both calls to getBits() get inlined into main().

The 4.6/4.7 inliner heuristics have changed somewhat, so getBits() do not get the same inlining no matter how hard I've tried so far :P

As for Linaro 4.5, the offending pattern appears after combine. I'll look into this later.

[Dr. David Alan Gilbert (davidgil-uk)]

Created attachment 24123
Produces bad assembler

This was originally reported as Linaro-gcc bug in Launchpad here:
https://bugs.launchpad.net/gcc-linaro/+bug/771903

The attached small test case fails with the assembler error:
gcc -O3 arm_bit_extract.c
/tmp/ccOOK26S.s: Assembler messages:
/tmp/ccOOK26S.s:97: Error: bit-field extends past end of register -- `ubfx r0,r0,#30,#10'

when compiled -O3 for ARMv7 on Ubuntu's gcc 4.5.2-8ubuntu1.
I'm told it also fails on vanilla 4.5.2

The shift that the source is trying to do is a bit bogus, however it shouldn't produce bad assembler.

Dave

[Dr. David Alan Gilbert (davidgil-uk)]

Upstream bug report is:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48803

[Ramana-gcc (ramana-gcc)]

Occurs on gcc 4.5 branch but not on 4.6 branch or trunk. Need to see where and why it got "fixed" .

Ramana

[Michael Hope (michaelh1)]

Part of the difference is that 4.5 inlines the other functions and 4.6 doesn't. Adding an __attribute__((always_inline)) to both gives the following:

For 4.5, main is:

main:
        movw r3, #22136
        movt r3, 4660
        and r3, r0, r3
        cbnz r3, .L10
        mvn r3, #15
        lsls r2, r0, r3
        ubfx r0, r0, #30, #10
        and r3, r0, #768
        lsrs r0, r2, #24
        orr r0, r3, r0
        bx lr
.L10:
        ubfx r3, r0, #22, #2
        lsrs r0, r0, #24
        lsls r3, r3, #8
        orr r0, r3, r0
        bx lr

For 4.6 it becomes:

main:
        movw r3, #22136
        movt r3, 4660
        ands r3, r3, r0
        cbz r3, .L13
        ubfx r3, r0, #22, #2
        lsrs r0, r0, #24
        lsls r3, r3, #8
.L12:
        orrs r0, r0, r3
        bx lr
.L13:
        mov r0, r3
        b .L12

[Michael Hope (michaelh1)]

Attached the upstream bug and followed up there.

[Mikpe (mikpe)]

This test case stopped failing, sort of, for 4.6 by r162943, the introduction of tree-bit-ccp optimization. However that revision merely masked the problem by default, as compiling with 4.6.[01] and -fno-tree-bit-ccp makes it reappear. The bug was finally fixed for 4.7 by r176911, the fix for the similar PR49799. That fix was also applied for 4.6.2 in r176917.

Backporting r176917 to 4.5 and 4.4 fixes both PRs there too.

[Michael Hope (michaelh1)]

The fault was fixed in the upstream release branch. Confirmed fixed in gcc-linaro-4.6-2011.09.

[Michael Hope (michaelh1)]

...but the original report was against 4.5. Exists in 4.5-2011.09-1.

[Michael Hope (michaelh1)]

I'm having a spring clean. Dave, this has been fixed in trunk and 4.6. Being aggressive and marking it as 'wont fix' for 4.5.

[Ramana-gcc (ramana-gcc)]

This is a 4.5 only bug and should probably be closed as 4.5 is now kind of dead.

Ramana