From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68110 invoked by alias); 22 Mar 2016 09:25:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 68086 invoked by uid 89); 22 Mar 2016 09:25:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Christophe, christophe, safest, HX-Envelope-From:sk:christo X-HELO: mail-qk0-f173.google.com Received: from mail-qk0-f173.google.com (HELO mail-qk0-f173.google.com) (209.85.220.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 22 Mar 2016 09:25:00 +0000 Received: by mail-qk0-f173.google.com with SMTP id p130so35801300qke.1 for ; Tue, 22 Mar 2016 02:25:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HnTZ6+qa3NzHom/uLOPZvqfxMaGJMl0ItKd6N2PochU=; b=ehtqJh6skkPIa3cwq5aYKqXhOEoKtrDkBLoJ1Plpjdpf3gf5RQasaMR+oCpYwWfjl7 KdmlxO6LpPb1pJJDQxja3Nz+rlfQrP2mTmCv9Qq0c7mAHyY4roYrHyOCb8qXNMCjMOfA dMCUUEyjf8k5BT2RE3n3b6huwieBHxC/S38EcqWNSPVkLbCWpncD+P7mnvI18gemq/Ah y5+GdyQ1uRLOPjbSuAz+1H59ENMqmGLNJy4T/lJS/gXprCkTC8CGY5bi2NHu4wWEPXLy mIgaTrmtvSGplPKZcUFRKZooGkO7ErmqlFIYbQp1AgwpmdC8Xf1IS5WnqChu+kMGnBFt gCsA== X-Gm-Message-State: AD7BkJK7+4Xjx9DI5ii5y1UWF5GssNRgsDdrpabvnr39hVy4sYwckimeshoCDPDl5u3f9gXSVWDJqSwC/kbSInDa MIME-Version: 1.0 X-Received: by 10.55.215.83 with SMTP id m80mr45195927qki.84.1458638698890; Tue, 22 Mar 2016 02:24:58 -0700 (PDT) Received: by 10.140.22.164 with HTTP; Tue, 22 Mar 2016 02:24:58 -0700 (PDT) In-Reply-To: <56EC322E.5080900@redhat.com> References: <56EBF12B.40701@t-online.de> <56EBF3B9.5050005@redhat.com> <56EC322E.5080900@redhat.com> Date: Tue, 22 Mar 2016 09:37:00 -0000 Message-ID: Subject: Re: Fix 70278 (LRA split_regs followup patch) From: Christophe Lyon To: Jeff Law Cc: Bernd Schmidt , GCC Patches , Vladimir Makarov Content-Type: multipart/mixed; boundary=001a1149e45c812634052e9fc9ab X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg01232.txt.bz2 --001a1149e45c812634052e9fc9ab Content-Type: text/plain; charset=UTF-8 Content-length: 1997 On 18 March 2016 at 17:51, Jeff Law wrote: > On 03/18/2016 06:25 AM, Bernd Schmidt wrote: >> >> This fixes an oversight in my previous patch here. I used biggest_mode >> in the assumption that if the reg was used in the function, it would be >> set to something other than VOIDmode, but that fails if we have a >> multiword access - only the first hard reg gets its biggest_mode >> assigned in that case. >> >> Bootstrapped and tested on x86_64-linux, ran (just) the new arm testcase >> manually with arm-eabi. Ok? >> >> (The testcase seems to be from glibc. Do we keep the copyright notices >> on the reduced form)? > > I don't recall specific guidance on including the copyright notice on a > reduced/derived test. > > Given the actual copyright on the original code, ISTM the safest thing to do > is keep the notice intact. > > A long long time ago I receive guidance from the FSF WRT what could be > included in the testsuite -- unfortunately I didn't keep that message. I > probably should have. > >> >> Bernd >> >> 70278.diff >> >> >> PR rtl-optimization/70278 >> * lra-constraints.c (split_reg): Handle the case where >> biggest_mode is >> VOIDmode. >> >> testsuite/ >> * gcc.dg/torture/pr70278.c: New test. >> * gcc.target/arm/pr70278.c: New test. > The ARM test isn't sufficiently protected against non-compliant configurations, and fails if GCC is configured for arm*linux-gnueabihf for instance (see http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/234342/report-build-info.html) The attached small patch fixes that by requiring arm_arch_v4t_multilib effective target. I used arm_arch_v4t_multilib instead of arm_arch_v4t because, as I reported a long time ago the later does not complain in some unsupported configuration because the sample effective target test does not contain actual code. In particular it's not sufficient to reject thumb-1 with hard-float. OK? Thanks, Christophe. > OK. > jeff > --001a1149e45c812634052e9fc9ab Content-Type: text/plain; charset=US-ASCII; name="pr70278.log.txt" Content-Disposition: attachment; filename="pr70278.log.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_im37tjse0 Content-length: 188 MjAxNi0wMy0yMiAgQ2hyaXN0b3BoZSBMeW9uICA8Y2hyaXN0b3BoZS5seW9u QGxpbmFyby5vcmc+CgoJKiBnY2MudGFyZ2V0L2FybS9wcjcwMjc4LmM6IFJl cXVpcmUgYXJtX2FyY2hfdjR0X211bHRpbGliCgllZmZlY3RpdmUgdGFyZ2V0 Lgo= --001a1149e45c812634052e9fc9ab Content-Type: text/plain; charset=US-ASCII; name="pr70278.patch.txt" Content-Disposition: attachment; filename="pr70278.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_im37to4i1 Content-length: 834 ZGlmZiAtLWdpdCBhL2djYy90ZXN0c3VpdGUvZ2NjLnRhcmdldC9hcm0vcHI3 MDI3OC5jIGIvZ2NjL3Rlc3RzdWl0ZS9nY2MudGFyZ2V0L2FybS9wcjcwMjc4 LmMKaW5kZXggYzQ0YzA3Yi4uODg5ZjYyNiAxMDA2NDQKLS0tIGEvZ2NjL3Rl c3RzdWl0ZS9nY2MudGFyZ2V0L2FybS9wcjcwMjc4LmMKKysrIGIvZ2NjL3Rl c3RzdWl0ZS9nY2MudGFyZ2V0L2FybS9wcjcwMjc4LmMKQEAgLTIsNiArMiw3 IEBACiAvKiB7IGRnLXNraXAtaWYgImF2b2lkIGNvbmZsaWN0aW5nIG11bHRp bGliIG9wdGlvbnMiIHsgKi0qLSogfSB7ICItbWFyY2g9KiIgfSB7ICItbWFy Y2g9YXJtdjR0IiB9IH0gKi8KIC8qIHsgZGctc2tpcC1pZiAiYXZvaWQgY29u ZmxpY3RpbmcgbXVsdGlsaWIgb3B0aW9ucyIgeyAqLSotKiB9IHsgIi1tYXJt IiB9IHsgIiIgfSB9ICovCiAvKiB7IGRnLW9wdGlvbnMgIi1tdGh1bWIiIH0g Ki8KKy8qIHsgZGctcmVxdWlyZS1lZmZlY3RpdmUtdGFyZ2V0IGFybV9hcmNo X3Y0dF9tdWx0aWxpYiB9ICovCiAvKiB7IGRnLWFkZC1vcHRpb25zIGFybV9h cmNoX3Y0dCB9ICovCiAvKgogICogPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo= --001a1149e45c812634052e9fc9ab--