[Bug c/70566] New: Bad ARM code generated for evaluating unsigned int bitfield value

["dan at reactivated dot net" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566

            Bug ID: 70566
           Summary: Bad ARM code generated for evaluating unsigned int
                    bitfield value
           Product: gcc
           Version: 5.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dan at reactivated dot net
  Target Milestone: ---

Created attachment 38204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38204&action=edit
main.c test case source

I have reproduced on gcc-4.9.2, gcc-4.9.3, and gcc-5.3.1 in Debian.

System type: ODROID-U2 (Exynos4412) ARMv7

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-13'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.3.1 20160323 (Debian 5.3.1-13) 



With a struct set up with bitfield values like this:

struct mystruct {
        unsigned int uid_set : 1;
        unsigned int is_loaded : 1;
        unsigned int nonexistent : 1;
};

The following C code is compiled to bad ARMv7 assembly under certain
circumstances at -O2:

        if (!user->is_loaded) 
                set_is_loaded (user, 1);

The resultant bad assembly is:

  14:   7803            ldrb    r3, [r0, #0]
  16:   079b            lsls    r3, r3, #30
  18:   d400            bmi.n   1c <on_get_all_finished+0x8>
  1a:   d000            beq.n   1e <on_get_all_finished+0xa>
  1c:   4770            bx      lr
  1e:   e7ef            b.n     0 <set_is_loaded.part.0>

In the bitfield, uid_set is bit 0 and is_loaded is bit 1.

The assembly loads the bitfield value and shifts left to have the value of
is_loaded at bit 31. So the "bmi" instruction makes perfect sense: if is_loaded
is set, jump to some code that is not going to call set_is_loaded.

The following "beq" instruction is bad. Here we have is_loaded at bit 31, but
we also have uid_set at bit 30. So the value of uid_set is clearly going to
influence the code behaviour here: if uid_set is 1, we will not call
set_is_loaded.

This issue originates from freedesktop's accountsservice where I noticed the
incorrect runtime behaviour.

I am attaching a minimal test case which you can compile with:
gcc -O2 -g -c main.c -o out.o
gcc -c other.c -o other.o
gcc other.o out.o -o prog

Run with:

./prog 0
./prog 1

The argument controls the value of uid_set. It should have no effect on the
runtime behaviour, but you'll notice that myfunc is only called when the arg is
0.

Unfortunately I couldn't figure out how to slim down the test case into a
single file, as that resulted in different (working) asm being generated.

I'm also attaching the preprocessed version of main.c.