http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> --- (In reply to Bernd Edlinger from comment #8) > (In reply to Martin Jambor from comment #7) > > In any event, it is clear that > > the code in expand_assignment cannot cope with unaligned tem and non-NULL > > offset. So currently I'm considering the following patch, although I am not > > really sure it is enough (it does fix the ICE, though). If you can run the > > testcase on the platform, would you run it with this patch applied, please? > > No, unfortunately I can only look at the assembler listing. > > But wait a moment... > > If the object is assumed to be unaligned here this patch will > likely just compute the unaligned address, add the offset, > and store the result there without any special precautions. > While the code in the if statement seems to store the expression > on a register and move that register to the final destination. > > Well, I believe this unaligned arrays are generally broken. > > consider this example: With or without the patch? If without the patch and you are reasonably confident the output is indeed wrong, please open a new PR (and CC me, I'm interested) because this particular ICE is certainly caused by trailing zero sized arrays. I have tried reproducing your problem with x86_64 MMX vectors but couldn't. I do not have access to an ARM machine to verify myself. Thanks.