From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25561 invoked by alias); 31 Jul 2012 17:57:14 -0000 Received: (qmail 25530 invoked by uid 22791); 31 Jul 2012 17:57:09 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Jul 2012 17:56:56 +0000 From: "ramana at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives Date: Tue, 31 Jul 2012 17:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ramana at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-07/txt/msg02276.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #12 from Ramana Radhakrishnan 2012-07-31 17:56:29 UTC --- (In reply to comment #8) > For some reason I couldn't apply the patch, but manually changed the tests to > use { scan-assembler-times regexp 2 } instead of { scan assembler regexp }. > > Ramana, have you tried running the tests? They should pass but don't. I'll > take a closer look at what scan-assembler-times and Tcl's regexp are doing. I finally tried this on fsf trunk and it applied cleanly for me here and ran the tests. The tests for vld2Q intrinsics appear to pass fine for me here. The changes related to vld2Q appear to be doing fine, there we've actually removed the redundant duplication and what appears to be a bug in the test generator. (In reply to comment #11) > Sorry, I had been assuming that the tests in our tree match what's upstream but > the expressions to match are slightly different. I'll keep investigating. Thanks for digging further - What I don't follow is why the scan-assembler-times appears to fail while the scan-assembler doesn't. FTR, the vld3Q and vld4Q intrinsics should indeed produce 2 vld3 and vld4 instructions. regards, ramana