Bug 48803 - arm: Bad assembler produced by bit extract/shift
Summary: arm: Bad assembler produced by bit extract/shift
Status: RESOLVED DUPLICATE of bug 49799
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.5.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2011-04-28 11:29 UTC by Dr. David Alan Gilbert
Modified: 2015-06-24 23:28 UTC (History)
3 users (show)

See Also:
Host:
Target: arm
Build:
Known to work: 4.6.2, 4.7.0
Known to fail: 4.5.2
Last reconfirmed: 2011-05-06 13:10:47


Attachments
Produces bad assembler (278 bytes, text/x-csrc)
2011-04-28 11:29 UTC, Dr. David Alan Gilbert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dr. David Alan Gilbert 2011-04-28 11:29:43 UTC
Created attachment 24123 [details]
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
Comment 1 Ramana Radhakrishnan 2011-05-06 13:10:47 UTC
Occurs on gcc 4.5 branch but not on 4.6 branch or trunk. Need to see where and why it got "fixed" .

Ramana
Comment 2 Michael Hope 2011-07-11 00:19:52 UTC
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
Comment 3 Mikael Pettersson 2011-09-22 19:29:38 UTC
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.
Comment 4 Ramana Radhakrishnan 2012-07-31 00:57:03 UTC
This is a 4.5 only bug and should probably be closed as 4.5 is now kind of dead. 

Ramana
Comment 5 Ramana Radhakrishnan 2015-06-24 23:28:49 UTC
Duplicate then of PR49799... About time we closed this.

*** This bug has been marked as a duplicate of bug 49799 ***