[Bug target/79145] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

["petr.cvek at tul dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

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

Petr Cvek <petr.cvek at tul dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |6.3.0
      Known to fail|                            |6.3.0

--- Comment #2 from Petr Cvek <petr.cvek at tul dot cz> ---
During buildroot for iwmmxt arch (PXA27x), several sources failed on this
error:

./z32.c: In function ‘main’:
./z32.c:20:1: error: unrecognizable insn:
 }
 ^
(insn 6 5 7 2 (set (reg:DI 111 [ t1.1_3 ])
        (xor:DI (reg:DI 110 [ t1.0_2 ])
            (const_int 85 [0x55]))) ./z32.c:13 -1
     (nil))
./z32.c:20:1: internal compiler error: in extract_insn, at recog.c:2287

Testing showed, that the error is caused by using an XOR when one operand is
long long and second is a constant char (or a variable optimized to the
constant). Different operand sizes are OK, using xscale target is OK and doing
XOR manually (by AND, OR and negation) is OK too.

Example program:

#define XOR(x,y) ((x & ! y) | (! x & y ))

int main(void) {

    volatile long long t1;

    t1 ^= 0x55;        //FAILS

    t1=XOR(t1,0x55);   //is OK

    return 0;
}

GCC was compiled by crosstool-ng, configuration:

# arm-unknown-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-unknown-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/vocore_mips_gcc/arm-unknown-linux-gnueabi/libexec/gcc/arm-unknown-linux-gnueabi/6.3.0/lto-wrapper
Target: arm-unknown-linux-gnueabi
Configured with:
/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/src/gcc-6.3.0/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-unknown-linux-gnueabi
--prefix=/opt/vocore_mips_gcc/arm-unknown-linux-gnueabi
--with-sysroot=/opt/vocore_mips_gcc/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot
--enable-languages=c,c++ --with-pkgversion='crosstool-NG
crosstool-ng-1.22.0-452-gc7b1e295' --enable-__cxa_atexit --enable-libmudflap
--enable-libgomp --enable-libssp --enable-libquadmath
--enable-libquadmath-support --enable-libsanitizer --disable-libmpx
--with-gmp=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--with-mpfr=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--with-mpc=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--with-isl=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--enable-lto --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix
--enable-target-optspace --enable-plugin
--with-libintl-prefix=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--enable-multiarch
--with-local-prefix=/opt/vocore_mips_gcc/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
gcc version 6.3.0 (crosstool-NG crosstool-ng-1.22.0-452-gc7b1e295) 

P.S. It is highly possible this bug is long time present (at least one/two
years).