From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27232 invoked by alias); 17 Nov 2004 19:19:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 27168 invoked from network); 17 Nov 2004 19:19:25 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 17 Nov 2004 19:19:25 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1CUVKv-000711-3T; Wed, 17 Nov 2004 11:19:25 -0800 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26552-08; Wed, 17 Nov 2004 11:19:25 -0800 (PST) Received: from egret.hq.tensilica.com ([192.168.11.80] ident=[TEwJtRVhN8zBnKusAh8cs1CtGKiw8amG]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1CUVKu-00070u-RX; Wed, 17 Nov 2004 11:19:24 -0800 Received: from tensilica.com (wintergreen.vpn.tensilica.com [172.16.12.1]) by egret.hq.tensilica.com (8.11.6/8.11.6) with ESMTP id iAHJJOw24824; Wed, 17 Nov 2004 11:19:24 -0800 Message-ID: <419BA411.5090801@tensilica.com> Date: Wed, 17 Nov 2004 19:20:00 -0000 From: Bob Wilson Organization: Tensilica, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: rth@redhat.com CC: gcc@gcc.gnu.org Subject: Re: [cft] subreg validation round 2 In-Reply-To: <20041117184009.GA12257@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hq.tensilica.com X-SW-Source: 2004-11/txt/msg00572.txt.bz2 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