Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00141.html
Thanks,
Kyrill
On 03/02/15 15:18, Kyrill Tkachov wrote:
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.tkac...@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.tkac...@arm.com>
PR target/64600
* gcc.target/arm/pr64600_1.c: New test.
