From patchwork Fri Feb 15 22:40:39 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Seth LaForge X-Patchwork-Id: 220889 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]) by ozlabs.org (Postfix) with SMTP id 6EE2A2C007A for ; Sat, 16 Feb 2013 09:41:13 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1361572873; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:From:Date:Message-ID:Subject:To:Cc: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=TNOt50M MFydzsqdhISkJkhxeUj8=; b=ZrExSVMOxWshdv5/EzwpbFjf71tVE600NhUd+5Q TUfQiFTlgwjlQCN6yDux7bKrxfU0yZkmXHEGtEMmly61GV4qoh4GdfViFFYeYMto mH6XOZKwyWiQH1G6Yp51RQ6GqMYAadkm7xLNp6wC29VADLI9G1kUurzB8qVoZa5N yXnA= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:X-Google-DKIM-Signature:X-Received:MIME-Version:Received:From:Date:Message-ID:Subject:To:Cc:Content-Type:X-Gm-Message-State:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=pAPFDF1CiJ5K9txzcMBhkqVZCvaHlxuVlFMa9y0JNZ11UY9SEhwXALDp89ccQw jO8x6EJzbZlNN9NmvlGDMAXzsDDRKjGbFpO6v0j4Bp/CUe3CMKWVThDF9sVh2eNY LTWGabflrvKl60dLTwxiFJ/dV+jSEqnlQLSfL8dsLgpZg=; Received: (qmail 5988 invoked by alias); 15 Feb 2013 22:41:09 -0000 Received: (qmail 5958 invoked by uid 22791); 15 Feb 2013 22:41:07 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vb0-f46.google.com (HELO mail-vb0-f46.google.com) (209.85.212.46) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Feb 2013 22:41:01 +0000 Received: by mail-vb0-f46.google.com with SMTP id b13so2503268vby.33 for ; Fri, 15 Feb 2013 14:41:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=lvewu+TQQ7CVhOrh7QDFd0wM1ZNBcawulsfQ+gAs/0s=; b=ERgf2pGYi9N5ZYkn0S1jAIhwAFgjy4xBTGvv0tezlmZeqZqI5/Dq7Vd29Thml8ZoQk WZZLsdwJj/RP3TI6MZPzSkpwCVnmuneHcy3oHce+dMcUkQv86uecUUNaHm0Y58+jnU09 m34YQEQ7hFoCMBukoB2QfeWXkkXBZmZFfRTEq06mmP11JsxtvvmHiRrId+njOvM5xmzF JQwIyJRdcjUmVc6EDqANC+13gDd2q4p8TKp6As7SP39+MykcB37LqY4WlW9REK7ym2/2 8FpfSpPyYMu9F0EYLNtsJnz0QILhCpCQe+Uy1xUFlHyfodrdpOccuP208GkLPRVe0ddw +nkQ== X-Received: by 10.52.96.134 with SMTP id ds6mr4671741vdb.107.1360968060090; Fri, 15 Feb 2013 14:41:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.173.73 with HTTP; Fri, 15 Feb 2013 14:40:39 -0800 (PST) From: Seth LaForge Date: Fri, 15 Feb 2013 14:40:39 -0800 Message-ID: Subject: Patch for 4.7: Avoid subreg'ing VFP D registers in big-endian mode To: gcc-patches@gcc.gnu.org Cc: Julian Brown X-Gm-Message-State: ALoCoQky5MnbI2LI8HkKVQ52tEikxBxsExjVYo4LGV3IU+KPRk4a+sLAdyqQQC4yiJyeC+KuZwREV0EfZ78CzVVCiTnlfET17Vgmj5iT2LY4gHYSNAXDSARc97WI/KakSQGc6gfnAHCCo4Qd4vY/GZXkIe/7s/AO0/iruhjcd9ePXRQWkDCM+BLuSbTuMl273f12WqWR+wf+ 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 gcc 4.7.2 generates incorrect code for big-endian ARM VFP processors when storing a local double to a packed memory location, as described in bug 56351. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56351 A fix has been submitted to the trunk by Julian Brown: http://gcc.gnu.org/git/?p=gcc.git;a=patch;h=4f0e4afcb2a9d345ed7e9c14233fb97d3a3e8d3c This fix is not included in the latest 4.7 snapshot. Can we please include it in the 4.7 branch so that this serious codegen bug is fixed in 4.7.3? Unfortunately, it's a not a trivial backport, as it appears that support for ARM FPA floating point has been removed from gcc since 4.7. Below is my best attempt at a backport - it works for me, on a big-endian VFP processor. I'm not familiar with this code, though - Julian, can you take a look and confirm whether I'm doing this right? 2013-02-15 Seth LaForge * config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Avoid subreg'ing VFP D registers in big-endian mode. Backported from a change by Julian Brown diff -urp gcc-4.7.2/gcc/config/arm/arm.h gcc-4.7.2.new/gcc/config/arm/arm.h --- gcc-4.7.2/gcc/config/arm/arm.h 2012-01-09 20:14:09.000000000 -0800 +++ gcc-4.7.2.new/gcc/config/arm/arm.h 2013-02-15 14:03:09.113531299 -0800 @@ -1123,11 +1123,18 @@ enum reg_class /* FPA registers can't do subreg as all values are reformatted to internal precision. In VFPv1, VFP registers could only be accessed in the mode they were set, so subregs would be invalid there too. However, we don't - support VFPv1 at the moment, and the restriction was lifted in VFPv2. */ + support VFPv1 at the moment, and the restriction was lifted in VFPv2. + In big-endian mode, modes greater than word size (i.e. DFmode) are stored in + VFP registers in little-endian order. We can't describe that accurately to + GCC, so avoid taking subregs of such values. */ #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ - (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ - ? reg_classes_intersect_p (FPA_REGS, (CLASS)) \ - : 0) + (TARGET_VFP \ + ? TARGET_BIG_END \ + && (GET_MODE_SIZE (FROM) > UNITS_PER_WORD \ + || GET_MODE_SIZE (TO) > UNITS_PER_WORD) \ + && reg_classes_intersect_p (VFP_REGS, (CLASS)) \ + : GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ + && reg_classes_intersect_p (FPA_REGS, (CLASS))) /* The class value for index registers, and the one for base regs. */ #define INDEX_REG_CLASS (TARGET_THUMB1 ? LO_REGS : GENERAL_REGS)