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