[Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020
aoliva at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Nov 26 21:58:00 GMT 2015
- Previous message (by thread): [Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020
- Next message (by thread): [Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67753
--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Author: aoliva
Date: Thu Nov 26 21:57:40 2015
New Revision: 230985
URL: https://gcc.gnu.org/viewcvs?rev=230985&root=gcc&view=rev
Log:
[PR67753] adjust for padding when bypassing memory in assign_parm_setup_block
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.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
- Previous message (by thread): [Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020
- Next message (by thread): [Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Gcc-bugs
mailing list