From patchwork Wed Apr 2 07:27:39 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 336266 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 244CE1400FA for ; Wed, 2 Apr 2014 18:27:53 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type; q=dns; s=default; b=fK+sZ6YtFu4qQnYGaCWwxHyLHk86+ptN9zT22MZt+bLIow5fXO aioiDaEBjd5kLOriZWskHAK2wjPJxIjXp2qHI2rwGodQkNIzU4scG7CDI5WvynLM 8Fko9YihezhO6a9lQqSTUNXP2p0q8/mkHvejXTC1NvI0Iyh/b+es5xacU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type; s= default; bh=5JDg4mx82yc3Y3e2Z4HP4ho/FY0=; b=rKwH4CtvPZIK2+phkhGH eajQStKwPqmPSg7xn/IIicjYV8Vw45X5WLrTnhenoE5bjG6Dpc03Q4qiaKQnjOxr E9l53E/+Ju6ckgrM1dT3kB8dDbw3T2TY8uASa/oxrMoLXO56QLJbwZ+AoxMSGVra tfhcwX/7gCg/xw48ldHvQfA= Received: (qmail 24439 invoked by alias); 2 Apr 2014 07:27:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 24423 invoked by uid 89); 2 Apr 2014 07:27:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Apr 2014 07:27:44 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s327RgeW029686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Apr 2014 03:27:42 -0400 Received: from littlehelper.redhat.com (vpn1-4-69.ams2.redhat.com [10.36.4.69]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s327RdwD011772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2014 03:27:41 -0400 From: Nick Clifton To: dj@redhat.com Cc: gcc-patches@gcc.gnu.org Subject: RFA: RL78: Fix handling of (SUBREG (SYMBOL_REF)) Date: Wed, 02 Apr 2014 08:27:39 +0100 Message-ID: <87vbusry1g.fsf@redhat.com> MIME-Version: 1.0 X-IsSubscribed: yes Hi DJ, The patch below is to fix a snafu I made whilst fixing some problems with the RL78 port a while ago. GCC was generating (SUBREG (SYMBOL_REF) ) which made no sense to me, so I had the movqi expander just fail when it encountered them. Now that I have more idea about why they are created - installing symbolic values into bitfields or packed structure fields - I have found that it is necessary to support them. Failure is not an option as GCC will just silently omit generating any code at all. Tested with an rl78-elf toolchain without any regressions. OK to apply ? Cheers Nick gcc/ChangeLog 2014-04-01 Nick Clifton * config/rl78/rl78-expand.md (movqi): Handle (SUBREG (SYMBOL_REF)) properly. Index: gcc/config/rl78/rl78-expand.md =================================================================== --- gcc/config/rl78/rl78-expand.md (revision 209009) +++ gcc/config/rl78/rl78-expand.md (working copy) @@ -30,18 +30,23 @@ if (rl78_far_p (operands[0]) && rl78_far_p (operands[1])) operands[1] = copy_to_mode_reg (QImode, operands[1]); - /* FIXME: Not sure how GCC can generate (SUBREG (SYMBOL_REF)), - but it does. Since this makes no sense, reject it here. */ + /* GCC can generate (SUBREG (SYMBOL_REF)) when it has to store a symbol + into a bitfield, or a packed ordinary field. We can handle this + provided that the destination is a register. If not, then load the + source into a register first. */ if (GET_CODE (operands[1]) == SUBREG - && GET_CODE (XEXP (operands[1], 0)) == SYMBOL_REF) - FAIL; + && GET_CODE (XEXP (operands[1], 0)) == SYMBOL_REF + && ! REG_P (operands[0])) + operands[1] = copy_to_mode_reg (QImode, operands[1]); + /* Similarly for (SUBREG (CONST (PLUS (SYMBOL_REF)))). cf. g++.dg/abi/packed.C. */ if (GET_CODE (operands[1]) == SUBREG && GET_CODE (XEXP (operands[1], 0)) == CONST && GET_CODE (XEXP (XEXP (operands[1], 0), 0)) == PLUS - && GET_CODE (XEXP (XEXP (XEXP (operands[1], 0), 0), 0)) == SYMBOL_REF) - FAIL; + && GET_CODE (XEXP (XEXP (XEXP (operands[1], 0), 0), 0)) == SYMBOL_REF + && ! REG_P (operands[0])) + operands[1] = copy_to_mode_reg (QImode, operands[1]); if (CONST_INT_P (operands[1]) && ! IN_RANGE (INTVAL (operands[1]), (-1 << 8) + 1, (1 << 8) - 1)) FAIL;