On Wed, 11 Sep 2013 15:43:53, Richard Biener wrote: > On Wed, Sep 11, 2013 at 3:41 PM, Bernd Edlinger > <bernd.edlin...@hotmail.de> wrote: >> On Tue, 10 Sep 2013 21:32:29, Martin Jambor wrote: >>> The misalignp path was added by you during the 4.7 development to fix >>> PR 50444 which was indeed about expansion of a SRA generated statement >>> >>> MEM[(struct Engine *)e_1(D) + 40B].m = SR.18_17; >>> >>> If I disable this path on the 4.7 branch, the testcase is compiled >>> incorrectly and aborts when run, apparently at least the 4.7's >>> combination of expand_normal and store_field cannot cope with it. >>> >>> The path no longer tests the testcase though, because the component >>> ref is not present in trunk, the LHS is now just >>> >>> MEM[(struct Engine *)e_3(D) + 40B] >>> >>> and so it is now handled just fine by the misaligned mem-ref case at >>> the beginning of expand_assignment. >> >> I tried to remove the misaligned mem-ref case at the beginning of the >> expand_assignment, just to see how it fails. I did this on trunk. >> >> But still all testcases pass, including pr50444.c... >> >> How can this be? > > Not sure. Can you try reverting the fix itself and bisect when the testcase > will start to pass? (maybe the testcase passed even without the fix?) > > Richard.
What I found out is this: If the movmisalign_optab is replaced by mov_optab it does still generate correct code. In 4.9, 4.8 and 4.7 too. The reason is that the back-end accesses MEM_ALIGN(to_rtx) in mov_optab and movmisalign_optab to decide if movdqa or movdqu is needed. While it is straight forward to remove the movmisalign path in 4.9 and 4.8, this is not so simple in the 4.7 branch. The reason is that 4.7 uses "to_rtx = expand_normal (tem);" while 4.8 and 4.9 use "to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);" which does almost the same, but returns the misaligned rtx instead of an register with the value of the structure. And the generated code without the misalign path fails simply because the assignment goes to the register instead of the structure. So the problem is: there is no EXPAND_WRITE/EXPAND_MEMORY in 4.7... A possible patch for 4.7 would be like the attached (untested) patch. With this pr50444.c, and pr57748-1..3.c would pass, but not pr57748-4.c as the read side would still be wrong, but back-porting this would be even more ugly :( Bernd.
patch-pr57748-4_7.diff
Description: Binary data
