On Mon, Feb 10, 2014 at 5:35 PM, Jeff Law wrote:
> On 02/07/14 02:17, Richard Biener wrote:
>>>
>>> +2014-02-05 Jeff Law
>>> +
>>> + PR middle-end/54041
>>> + * expr.c (expand_expr_addr_1): Handle expand_expr returning an
>>> + object with an undesirable mode.
>>> +
>>> 2014
On 02/07/14 02:17, Richard Biener wrote:
+2014-02-05 Jeff Law
+
+ PR middle-end/54041
+ * expr.c (expand_expr_addr_1): Handle expand_expr returning an
+ object with an undesirable mode.
+
2014-02-05 Bill Schmidt
* config/rs6000/rs6000.c (altivec_expand_vec_perm
On 02/07/14 02:17, Richard Biener wrote:
diff --git a/gcc/expr.c b/gcc/expr.c
index 878a51b..9609c45 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7708,6 +7708,11 @@ expand_expr_addr_expr_1 (tree exp, rtx target, enum
machine_mode tmode,
modifier == EXPAND_INITIALIZER
On Thu, Feb 6, 2014 at 8:33 PM, Jeff Law wrote:
>
> expand_expr has, for as long as I can remember, had the ability to ignore
> the desired mode provided by its callers and instead returning something in
> a completely different mode. It's always been the caller's responsibility
> to deal with th
expand_expr has, for as long as I can remember, had the ability to
ignore the desired mode provided by its callers and instead returning
something in a completely different mode. It's always been the caller's
responsibility to deal with that.
For the testcase in 54041, we call expand_expr w
