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

--- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 9 Jan 2019, dongjianqiang2 at huawei dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> 
> --- Comment #23 from John Dong <dongjianqiang2 at huawei dot com> ---
> diff -urp a/gcc/expr.c b/gcc/expr.c
> --- a/gcc/expr.c        2019-01-09 03:19:03.750205982 +0800
> +++ b/gcc/expr.c        2019-01-09 03:38:23.414174738 +0800
> @@ -10760,6 +10760,16 @@ expand_expr_real_1 (tree exp, rtx target
>                 && GET_MODE_CLASS (ext_mode) == MODE_INT)
>               reversep = TYPE_REVERSE_STORAGE_ORDER (type);
> 
> +               int modePrecision = GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE
> (tem)));
> +               int typePrecision = TYPE_PRECISION (TREE_TYPE (tem));
> +               int shiftSize = modePrecision - typePrecision;
> +               rtx regTarget = gen_reg_rtx (GET_MODE (op0));
> +
> +               if (shiftSize && REG_P (op0))
> +                 op0 = expand_shift (LSHIFT_EXPR, GET_MODE (op0), op0,
> +                                     shiftSize, regTarget,
> +                                     TYPE_UNSIGNED (TREE_TYPE (tem)));
> +
>             op0 = extract_bit_field (op0, bitsize, bitpos, unsignedp,
>                                      (modifier == EXPAND_STACK_PARM
>                                       ? NULL_RTX : target),
> 
> Tried to fix the bug when expand.

The bug is clearly in value-numbering, not RTL expansion

Reply via email to