On 11/10/2015 03:58 PM, Alexandre Oliva wrote:
On Nov 10, 2015, Alan Lawrence <alan.lawre...@arm.com> wrote:
FAIL: gcc.target/aarch64/aapcs64/func-ret-4.c execution, -O2
Ugh, sorry. I even checked that testcase by hand before submitting the
patch, because I knew it took the paths I was changing, but I didn't
realize the stack store and load would amount to shifts when the stack
slot was bypassed.
With the following patch, we get a lsr and a ubfx, without the sp
adjustments. Please let me know if it causes any further problems. So
far, I've tested it on x86_64-linux-gnu, i686-linux-gnu, and
ppc64le-linux-gnu; the ppc64-linux-gnu test run is running slower and
probably won't be done before I call it a day, but I wanted to give you
something before taking off for the day.
Is this ok to install if ppc64-linux-gnu also regstraps successfully?
[PR67753] adjust for padding when bypassing memory in assign_parm_setup_block
From: Alexandre Oliva <aol...@redhat.com>
Storing a register in memory as a full word and then accessing the
same memory address under a smaller-than-word mode amounts to
right-shifting of the register word on big endian machines. So, if
BLOCK_REG_PADDING chooses upward padding for BYTES_BIG_ENDIAN, and
we're copying from the entry_parm REG directly to a pseudo, bypassing
any stack slot, perform the shifting explicitly.
This fixes the miscompile of function_return_val_10 in
gcc.target/aarch64/aapcs64/func-ret-4.c for target aarch64_be-elf
introduced in the first patch for 67753.
for gcc/ChangeLog
PR rtl-optimization/67753
PR rtl-optimization/64164
* function.c (assign_parm_setup_block): Right-shift
upward-padded big-endian args when bypassing the stack slot.
Don't you need to check the value of BLOCK_REG_PADDING at runtime? The
padding is essentially allowed to vary.
If you look at the other places where BLOCK_REG_PADDING is used, it's
checked in a #ifdef, then again inside a if conditional.
Jeff
