From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24776 invoked by alias); 6 Nov 2015 17:25:57 -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 24751 invoked by uid 89); 6 Nov 2015 17:25:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Nov 2015 17:25:54 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-1-sOxJLwzoSW6ZYoQPJyBrbg-1; Fri, 06 Nov 2015 17:25:49 +0000 Received: from [10.2.207.43] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2015 17:25:49 +0000 Message-ID: <563CE29C.4030806@arm.com> Date: Fri, 06 Nov 2015 17:25:00 -0000 From: Renlin Li User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Biener , Ramana Radhakrishnan CC: gcc-patches , Ramana Radhakrishnan , Marcus Shawcroft , Jeff Law Subject: Re: [PING][PATCH][4.9]Backport "Fix register corruption bug in ree" References: <1C23526A7C42DB45BBF55B662C7C530E430D20FFFD@BUNGLE.Emea.Arm.com> <552F81BF.9020800@arm.com> <55704FC0.2030401@arm.com> <882D37CB-B796-4625-BD49-B76AA1393B8E@suse.de> In-Reply-To: <882D37CB-B796-4625-BD49-B76AA1393B8E@suse.de> X-MC-Unique: sOxJLwzoSW6ZYoQPJyBrbg-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00692.txt.bz2 Hi Richard, I am trying to come up with a simple test case, but failed to do so. I have isolated the function where bug is triggered. However, in order=20 to make it a useful test case, the silently corrupted register should be=20 used somewhere, and should affect the correctness of the program. I=20 cannot create such an context. libstdc++-v3/testsuite/tr1/8_c_compatibility/complex/50880.cc is a=20 concreted example which will trigger this bug. Here is a short description about why the test case failed: wrong code-gen in ree pass: (insn 279 278 531 2 (set (reg:TF 32 v0) (zero_extend:TF (reg:DI 19 x19 [orig:150 __x+8 ] [150])))=20 /libstdc++-v3/include/complex:861 691 {aarch64_movtflow_di} (nil)) (insn 531 279 275 2 (set (reg:TF 3 x3) (reg:TF 32 v0)) /libstdc++-v3/include/complex:861 -1 (nil)) (insn 275 531 510 2 (set (reg:DI 23 x23 [orig:151 __y ] [151]) (mem:DI (plus:DI (reg/v/f:DI 0 x0 [orig:104 __z ] [104]) (const_int 16 [0x10])) [9 MEM[(const long double=20 &)__z_4(D) + 16]+0 S8 A128])) /libstdc++-v3/include/complex:859 34=20 {*movdi_aarch64} (nil)) (insn 510 275 19 2 (set (zero_extract:TF (reg:TF 32 v0) (const_int 64 [0x40]) (const_int 64 [0x40])) (zero_extend:TF (reg:DI 2 x2 [ __x+-8 ])))=20 /libstdc++-v3/include/complex:861 689 {aarch64_movtfhigh_di} (nil)) insn 531 clobbers x4 as well. That's exactly the same problem described=20 in Wilco's email. The following is what the correct code should look=20 like. It's generated after applying Wilco's fix. (insn 279 278 275 2 (set (reg:DI 3 x3 [orig:185 __x ] [185]) (reg:DI 19 x19 [orig:150 __x+8 ] [150]))=20 /libstdc++-v3/include/complex:861 34 {*movdi_aarch64} (nil)) (insn 275 279 509 2 (set (reg:DI 23 x23 [orig:151 __y ] [151]) (mem:DI (plus:DI (reg/v/f:DI 0 x0 [orig:104 __z ] [104]) (const_int 16 [0x10])) [9 MEM[(const long double=20 &)__z_4(D) + 16]+0 S8 A128])) /libstdc++-v3/include/complex:859 34=20 {*movdi_aarch64} (nil)) (insn 509 275 510 2 (set (reg:TF 32 v0) (zero_extend:TF (reg:DI 3 x3 [orig:185 __x ] [185])))=20 /libstdc++-v3/include/complex:861 691 {aarch64_movtflow_di} (nil)) (insn 510 509 19 2 (set (zero_extract:TF (reg:TF 32 v0) (const_int 64 [0x40]) (const_int 64 [0x40])) (zero_extend:TF (reg:DI 2 x2 [ __x+-8 ])))=20 /libstdc++-v3/include/complex:861 689 {aarch64_movtfhigh_di} (nil)) Regards, Renlin Li On 29/10/15 16:33, Richard Biener wrote: > On October 29, 2015 4:37:08 PM GMT+01:00, Ramana Radhakrishnan wrote: >> On Thu, Jun 4, 2015 at 2:16 PM, Renlin Li wrote: >>> Ping ~ >>> >>> Can somebody review it? Thank you! >>> >>> Regards, >>> Renlin Li >>> >>> >>> On 16/04/15 10:32, Renlin Li wrote: >>>> Ping~ >>>> >>>> Regards, >>>> Renlin Li >>>> >>>> On 16/04/15 10:09, wrote: >>>>> Ping~ >>>>> Anybody has time to review it? >>>>> >>>>> >>>>> Regards, >>>>> Renlin Li >>>>> >>>>> On 06/02/15 17:48, Renlin Li wrote: >>>>>> Hi all, >>>>>> >>>>>> This is a backport patch for branch 4.9. You can find the >> original=3D20 >>>>>> patch >> here:https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00356.html >>>>>> And it has been commit on the trunk as r215205. >>>>>> >>>>>> This fixes a few libstdc++-v3 test suite failures. >>>>>> x86_64 bootstraps Okay, aarch64_be-none-elf libstdc++-v3 tested >> Okay. >>>>>> Okay to commit on branch 4.9? >>>>>> >>>>>> Regards, >>>>>> Renlin Li >>>>>> >>>>>> 2015-02-06 Renlin Li >>>>>> >>>>>> Backport from mainline >>>>>> 2014-09-12 Wilco Dijkstra >>>>>> >>>>>> * gcc/ree.c (combine_reaching_defs): Ensure inserted copy >> don't=3D20 >>>>>> change >>>>>> the number of hard registers. >>>>>> >> richi - an RM question - >> >> Is this something that can be pulled back to GCC 4.9 branch assuming >> testing still shows no regressions - it breaks aarch64 be on GCC 4.9 > If it is a regression or wrong-code fix its OK with a test case. > > Richard. > >> ... >> >> >> regards >> Ramana >