On 8/17/19 1:44 AM, Bernd Edlinger wrote: > On 8/15/19 9:47 PM, Bernd Edlinger wrote: >> Hi, >> >> this is the split out part from the "Fix not 8-byte aligned ldrd/strd on >> ARMv5 (PR 89544)" >> which is sanitizing the middle-end interface to the back-end for strict >> alignment, >> and a couple of bug-fixes that are necessary to survive boot-strap. >> It is intended to be applied after the PR 89544 fix. >> >> I think it would be possible to change the default implementation of >> STACK_SLOT_ALIGNMENT >> to make all stack variables always naturally aligned instead of doing that >> only >> in assign_parm_setup_stack, but would still like to avoid changing too many >> things >> that do not seem to have a problem. Since this would affect many targets, >> and more >> kinds of variables that may probably not have a strict alignment problem. >> But I am ready to take your advice though. >> >> >> Boot-strapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf >> Is it OK for trunk? >> >> > > Hmm, actually the hunk in assign_parm_setup_stack is not only failing > an assertion, but rather a wrong code bug: > > I found now a test case that generates silently wrong code and is fixed > by this patch. > > $ cat unaligned-argument-3.c > /* { dg-do compile } */ > /* { dg-require-effective-target arm_arm_ok } */ > /* { dg-options "-marm -mno-unaligned-access -O3" } */ > > typedef int __attribute__((aligned(1))) s; > > void x(char*, s*); > void f(char a, s f) > { > x(&a, &f); > } > > /* { dg-final { scan-assembler-times "str\t\[^\\n\]*\\\[sp\\\]" 1 } } */ > /* { dg-final { scan-assembler-times "str\t\[^\\n\]*\\\[sp, #3\\\]" 0 } } */ > > currently with -marm -mno-unaligned-access -O3 we generate: > > f: > @ args = 0, pretend = 0, frame = 8 > @ frame_needed = 0, uses_anonymous_args = 0 > str lr, [sp, #-4]! > sub sp, sp, #12 > mov r3, r0 > str r1, [sp, #3] <- may trap > add r0, sp, #7 > add r1, sp, #3 > strb r3, [sp, #7] > bl x > add sp, sp, #12 > @ sp needed > ldr pc, [sp], #4 > > > So I would like to add a test case to the patch as attached. > > Tested with a cross, that both dg-final fail currently and are fixed > with the other patches applied. > > Is it OK for trunk? OK when the patch that fixes this is ACK'd.
jeff