[PATCH] Fix expansion of initializer extensions (PR c/80163)

Jeff Law law@redhat.com
Mon Mar 27 15:52:00 GMT 2017


On 03/24/2017 12:58 PM, Jakub Jelinek wrote:
> Hi!
>
> As can be seen on the following testcase, when expanding an extension
> in EXPAND_INITIALIZER context, we emit wrong extension operation
> (one depending on the signedness of the result type rather than
> on the signedness of the argument type, so e.g. extension of
> unsigned int to long long int is done using SIGN_EXTEND instead of
> ZERO_EXTEND, and extension of int to unsigned long long int using
> ZERO_EXTEND instead of SIGN_EXTEND.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?
>
> 2017-03-24  Jakub Jelinek  <jakub@redhat.com>
>
> 	PR c/80163
> 	* expr.c <CASE_CONVERT>: For EXPAND_INITIALIZER determine SIGN_EXTEND
> 	vs. ZERO_EXTEND based on signedness of treeop0's type rather than
> 	signedness of the result type.
>
> 	* gcc.dg/torture/pr80163.c: New test.
>
> --- gcc/expr.c.jj	2017-03-07 09:04:04.000000000 +0100
> +++ gcc/expr.c	2017-03-24 12:09:57.729854079 +0100
> @@ -8333,7 +8333,8 @@ expand_expr_real_2 (sepops ops, rtx targ
>  	}
>
>        else if (modifier == EXPAND_INITIALIZER)
> -	op0 = gen_rtx_fmt_e (unsignedp ? ZERO_EXTEND : SIGN_EXTEND, mode, op0);
> +	op0 = gen_rtx_fmt_e (TYPE_UNSIGNED (TREE_TYPE (treeop0))
> +			     ? ZERO_EXTEND : SIGN_EXTEND, mode, op0);
?!?

Shouldn't the zero/sign extension be derived from the target's type not 
the source types?

treeop0 is the first source operand, isn't it?

Am I missing something here?
jeff





More information about the Gcc-patches mailing list