On Sun, Sep 15, 2013 at 6:55 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > Hello Richard, > > attached is my second attempt at fixing PR 57748. This time the movmisalign > path is completely removed and a similar bug in the read handling of > misaligned > structures with a non-BLKmode is fixed too. There are several new test cases > for the > different possible failure modes. > > This patch was boot-strapped and regression tested on > x86_64-unknown-linux-gnu > and i686-pc-linux-gnu. > > Additionally I generated eCos and an eCos-application (on ARMv5 using packed > structures) with an arm-eabi cross compiler, and looked for differences in the > disassembled code with and without this patch, but there were none. > > OK for trunk?
I agree that the existing movmisaling path that you remove is simply bogus, so removing it looks fine to me. Can you give rationale to @@ -4773,6 +4738,8 @@ expand_assignment (tree to, tree from, b if (MEM_P (to_rtx) && GET_MODE (to_rtx) == BLKmode && GET_MODE (XEXP (to_rtx, 0)) != VOIDmode + && bitregion_start == 0 + && bitregion_end == 0 && bitsize > 0 && (bitpos % bitsize) == 0 && (bitsize % GET_MODE_ALIGNMENT (mode1)) == 0 and especially to @@ -9905,7 +9861,7 @@ expand_expr_real_1 (tree exp, rtx target && modifier != EXPAND_STACK_PARM ? target : NULL_RTX), VOIDmode, - modifier == EXPAND_SUM ? EXPAND_NORMAL : modifier); + EXPAND_MEMORY); /* If the bitfield is volatile, we want to access it in the field's mode, not the computed mode. which AFAIK makes "memory" expansion of loads/stores from/to registers change (fail? go through stack memory?) - see handling of non-MEM return values from that expand_expr call. That is, do you see anything break with just removing the movmisalign path? I'd rather install that (with the new testcases that then pass) separately as this is a somewhat fragile area and being able to more selectively bisect/backport would be nice. Thanks, Richard. > Regards > Bernd.