This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [cft] subreg validation round 2
- From: Bob Wilson <bwilson at tensilica dot com>
- To: rth at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 17 Nov 2004 11:18:41 -0800
- Subject: Re: [cft] subreg validation round 2
- Organization: Tensilica, Inc.
Richard Henderson wrote:
This passes on i686, alpha, ia64, powerpc linux, and sparc-solaris.
Given Ulrich's previous testing, it *ought* to pass on s390. Any
other takers before I check it in and have to pick up pieces after
the fact?
I just finished testing the previous version of the patch for Xtensa, and I
didn't see any regressions. I'll try this version, too.
But speaking of picking up pieces after the fact....
Your change to assign_parm_setup_block() on 2004-11-13 is causing/exposing a
problem for Xtensa targets. Specifically, this piece:
*************** assign_parm_setup_block (tree parm, stru
*** 2648,2654 ****
{
rtx tem, x;
int by = (UNITS_PER_WORD - size) * BITS_PER_UNIT;
! rtx reg = gen_rtx_REG (word_mode, REGNO (data->entry_parm));
x = expand_shift (LSHIFT_EXPR, word_mode, reg,
build_int_cst (NULL_TREE, by),
--- 2663,2669 ----
{
rtx tem, x;
int by = (UNITS_PER_WORD - size) * BITS_PER_UNIT;
! rtx reg = gen_lowpart (word_mode, entry_parm);
x = expand_shift (LSHIFT_EXPR, word_mode, reg,
build_int_cst (NULL_TREE, by),
The Xtensa FUNCTION_ARG macro is returning a BLKmode REG for a 3-byte struct
argument. This used to be converted to an SImode REG, but now it gets passed to
gen_lowpart, which barfs on the BLKmode argument.
Is this my bug? If so, should I change FUNCTION_ARG code to avoid returning a
BLKmode reg? Should I wrap the REG in a PARALLEL? Something else?
My apologies if this has already been discussed -- I haven't kept up with recent
changes very well.
Thanks,
--Bob