From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110977 invoked by alias); 14 Oct 2016 19:35:08 -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 110959 invoked by uid 89); 14 Oct 2016 19:35:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=INTEREST, interest X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Oct 2016 19:35:06 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2018C81F03; Fri, 14 Oct 2016 19:35:05 +0000 (UTC) Received: from vpn-237-192.phx2.redhat.com (vpn-237-192.phx2.redhat.com [10.3.237.192]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EJZ3rr014242; Fri, 14 Oct 2016 15:35:04 -0400 Message-ID: <1476473703.10766.37.camel@redhat.com> Subject: Re: [PATCH] Add "__RTL" to cc1 (v2) From: David Malcolm To: Bernd Schmidt , Richard Biener Cc: Joseph Myers , GCC Patches Date: Fri, 14 Oct 2016 19:35:00 -0000 In-Reply-To: <59c65410-be48-d93d-e3df-1b2279414eea@redhat.com> References: <1475855912-44611-1-git-send-email-dmalcolm@redhat.com> <1476473155.10766.33.camel@redhat.com> <59c65410-be48-d93d-e3df-1b2279414eea@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg01198.txt.bz2 On Fri, 2016-10-14 at 21:27 +0200, Bernd Schmidt wrote: > On 10/14/2016 09:25 PM, David Malcolm wrote: > > > > The behavior probably should be that it runs the remainder of the > > RTL > > passes from some specified point, and generates valid assembler (so > > that we can have dg-do DejaGnu tests). > > Actually I had imagined that tests would specify before and after RTL > so > that we verify that the pass we're testing does what it's supposed to > do. Note that this approach would allow for: { dg-final { scan-rtl-dump "SOMETHING" "PASS OF INTEREST" } } */ directives in the .c file, so it would support specifying the "after RTL" to some extent.