Hi,
> But the coment previously read
>
> /* A constant address in TO_RTX can have VOIDmode, we must not try
> to call force_reg for that case. Avoid that case. */
>
> and you are removing that check. So I guess you want to retain
>
> && GET_MODE (XEXP (to_rtx, 0)) != VOIDmode
>
> or investigate why we don't need to avoid this case anymore. In fact,
> that's probably the only change necessary, just drop the == BLKmode
> check? Your lengthy description doesn't reveal if you investigated that.
> It seems to me it tries to avoid ajdusting MEM (symbol-ref) for example?
> Maybe also for optimization reasons?
I have now found out, what kind of MEM it is, which has a VOIDmode address...
Just a few lines above, there is this:
if (!MEM_P (to_rtx))
{
/* We can get constant negative offsets into arrays with broken
user code. Translate this to a trap instead of ICEing. */
gcc_assert (TREE_CODE (offset) == INTEGER_CST);
expand_builtin_trap ();
to_rtx = gen_rtx_MEM (BLKmode, const0_rtx);
}
now, I have never ever seen this block executed.
Even the examples from PR 23714 do not execute this block any more.
But const0_rtx has VOIDmode. This would satisfy the condition.
So if I try:
to_rtx = gen_rtx_MEM (BLKmode, const0_rtx);
force_reg(mode1, to_rtx);
Voila: assertion in emit_move_insn.
Somehow this matches literally to what Jeff wrote in the comment:
"A constant address in TO_RTX can have VOIDmode, we must not try
to call force_reg for that case."
But nothing happens with:
to_rtx = gen_rtx_MEM (BLKmode, const0_rtx);
to_rtx = adjust_address (to_rtx, mode1, bitpos / BITS_PER_UNIT)
also the rest of the code generation works, and of course this
expands a null pointer access.
> Adding a new comment before the block reflecting your analysis above
> would be nice as well.
done, see the attached patch v2.
I have also removed the check for MEM_P (to_rtx) in the first if-statement,
because this is always satisfied, after the if (!MEM_P(to_rtx))-block above.
Now both places have exactly the same logic.
Boot-strapped & regression-tested in x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
2014-05-27 Bernd Edlinger <bernd.edlin...@hotmail.de>
* expr.c (expand_assignment): Fold the bitpos in the to_rtx if
sufficiently aligned and an offset is used at the same time.
(expand_expr_real_1): Likewise.
patch-expr.diff
Description: Binary data
