On Wed, May 28, 2014 at 11:02 AM, Bernd Edlinger
<bernd.edlin...@hotmail.de> wrote:
> 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?
Ok.
Thanks,
Richard.
>
> Thanks
> Bernd.
>
