Hi all,

The ICE in this PR occurs when -mtune=xscale triggers a particular path 
through arm_gen_constant during expand
that creates a 0xfffff00f mask but for a 64-bit HOST_WIDE_INT doesn't 
sign extend it into
0xfffffffffffff00f that signifies the required -4081. It leaves it as 
0xfffff00f (4294963215) that breaks when
later combine tries to perform an SImode bitwise AND using the wide-int 
machinery.

I think the correct approach here is to use trunc_int_for_mode that 
correctly sign-extends the constant so
that it is properly represented by a HOST_WIDE_INT for the required mode.

Bootstrapped and tested arm-none-linux-gnueabihf with -mtune=xscale in 
BOOT_CFLAGS.

The testcase triggers for -mcpu=xscale and all slowmul targets because 
they are the only ones that have the
constant_limit tune parameter set to anything >1 which is required to 
follow this particular path through
arm_split_constant. Also, the rtx costs can hide this ICE sometimes.

Ok for trunk?

Thanks,
Kyrill

2015-02-03  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     PR target/64600
     * config/arm/arm.c (arm_gen_constant, AND case): Call
     trunc_int_for_mode when constructing AND mask.

2015-02-03  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     PR target/64600
     * gcc.target/arm/pr64600_1.c: New test.