From patchwork Mon Feb 9 15:11:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alex Velenko X-Patchwork-Id: 437961 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 A0274140142 for ; Tue, 10 Feb 2015 02:12:31 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=yHu3TUobo/6w13+1Kc3R0JjchQdi6SwSv+QzjifvzY+yHzGmNag/v 9C3NrBtKg0ZyfR3f2qlL4VtDSH7RB+XJiyIvqifq6MoundTyQtfDhUSuaQj6vmzg bukUF9skkceJ0FlxxLcvMQUTOqLqTQcb9MrdLKFbbjGMCzewKkp2r4= 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 :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=default; bh=RQ10mq6RFBxJd/uvyxWy0jdFK+E=; b=ulrGkGhBGv8aov2aPydZJqjAy1+I BURtMmJXcetURV1VjKomrY2zGMmBk0+cFvNnSos9XRH5VtmAMu90sYhUvUftkhGi C71mYP2IgzOCadFOLxkgk52ipvswYm7PlhzXwwnztnWh8v6pDAGl1bcQTL3LB2yA Lif4k2w2OZfmsGs= Received: (qmail 21198 invoked by alias); 9 Feb 2015 15:11:52 -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 21181 invoked by uid 89); 9 Feb 2015 15:11:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Feb 2015 15:11:50 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by service87.mimecast.com; Mon, 09 Feb 2015 15:11:46 +0000 Received: from [10.2.207.44] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2015 15:11:45 +0000 Message-ID: <54D8CE31.6090503@arm.com> Date: Mon, 09 Feb 2015 15:11:45 +0000 From: Alex Velenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mike Stump , Marcus Shawcroft CC: "gcc-patches@gcc.gnu.org" , Marcus Shawcroft Subject: Re: Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME References: <1422375847-18680-1-git-send-email-alex.velenko@arm.com> <58101C4C-374A-43E5-B255-C97CE3046A2C@comcast.net> In-Reply-To: <58101C4C-374A-43E5-B255-C97CE3046A2C@comcast.net> X-MC-Unique: 115020915114610801 X-IsSubscribed: yes On 28/01/15 18:50, Mike Stump wrote: > On Jan 28, 2015, at 9:51 AM, Marcus Shawcroft wrote: >> Going forward we can [ … ] xfail the test case pending a proper solution to >> 59448 ? > >> Mike do you prefer one of the other two approaches ? > > I’d xfail the test case and mark with the fix consume PR. If we don’t have an unambiguous, fix consume PR, I’d file that. It should be listed as failing on aarch, and the fix for that PR should then make the aarch test case pass. This way no one can run off with the PR and do anything else with it. > Hi, Mike! Sorry for the delay. The following patch makes atomic-op-consume.c XFAIL for both gcc.target/arm and gcc.target/aarch64 tests. XFAIL was chosen as prefered approach for handling __ATOMIC_CONSUME to __ATOMIC_ACQUIRE promotion workaround. This patch was tested by running the modified tests on aarch64-none-elf and arm-none-eabi compilers. Is this patch ok? Alex 2015-02-09 Alex Velenko gcc/testsuite/ * gcc.target/aarch64/atomic-op-consume.c (scan-assember-times): Directive adjusted to XFAIL. * gcc.target/arm/atomic-op-consume.c (scan-assember-times): Directive adjusted to XFAIL. +/* { dg-final { scan-assembler-times "ldrex\tr\[0-9\]+, \\\[r\[0-9\]+\\\]" 6 { xfail *-*-* } } } */ /* { dg-final { scan-assembler-times "strex\t...?, r\[0-9\]+, \\\[r\[0-9\]+\\\]" 6 } } */ /* { dg-final { scan-assembler-not "dmb" } } */ --------------1.8.1.2-- diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c index 38d6c2c..8150af6 100644 --- a/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c +++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c @@ -3,5 +3,9 @@ #include "atomic-op-consume.x" -/* { dg-final { scan-assembler-times "ldxr\tw\[0-9\]+, \\\[x\[0-9\]+\\\]" 6 } } */ +/* To workaround Bugzilla 59448 issue, a request for __ATOMIC_CONSUME is always + promoted to __ATOMIC_ACQUIRE, implemented as MEMMODEL_ACQUIRE. This causes + "LDAXR" to be generated instead of "LDXR". Therefore, "LDXR" test is + expected to fail. */ +/* { dg-final { scan-assembler-times "ldxr\tw\[0-9\]+, \\\[x\[0-9\]+\\\]" 6 { xfail *-*-* } } } */ /* { dg-final { scan-assembler-times "stxr\tw\[0-9\]+, w\[0-9\]+, \\\[x\[0-9\]+\\\]" 6 } } */ diff --git a/gcc/testsuite/gcc.target/arm/atomic-op-consume.c b/gcc/testsuite/gcc.target/arm/atomic-op-consume.c index cc6c028..060655c 100644 --- a/gcc/testsuite/gcc.target/arm/atomic-op-consume.c +++ b/gcc/testsuite/gcc.target/arm/atomic-op-consume.c @@ -7,7 +7,8 @@ /* To workaround Bugzilla 59448 issue, a request for __ATOMIC_CONSUME is always promoted to __ATOMIC_ACQUIRE, implemented as MEMMODEL_ACQUIRE. This causes - "LDAEX" to be generated instead of "LDREX". */ -/* { dg-final { scan-assembler-times "ldaex\tr\[0-9\]+, \\\[r\[0-9\]+\\\]" 6 } } */ + "LDAEX" to be generated instead of "LDREX". Therefore, "LDREX" test is + expected to fail. */