From patchwork Thu Jun 5 14:10:46 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Teresa Johnson X-Patchwork-Id: 356423 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 EC35F140093 for ; Fri, 6 Jun 2014 00:11:13 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:date:message-id:subject:from:to:cc:content-type; q=dns; s=default; b=UYQQonix07WUcBeYiWl8eHYQAHj0vDM7peUpfw8MuJm l7/McYjcAZd7qycyUMPc4nhk5kWDVyCHrHAoMv57K7QYfG0LlsAbJ9G/+Xn4PU56 0mFB6Fc4b+2dRQjF1GzDSXpin8LWaa9Yl2vj2OgCWzg1n/PqtGATzBpvQG/OEOOU = 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 :mime-version:date:message-id:subject:from:to:cc:content-type; s=default; bh=JrJ3t8YuMhK45aZRJpWLzze2zYo=; b=WRjWJmlmTcPTKwtm6 AXcJu+EfVvpuD+m7B1G2mQc5cuShP1LS/hEb/9pCy80tjleeDRM3+hpvRxUkDfyk 6LHwfpSGHr6j5rikZ0dtYNKDxcQdw2e1ghKJttrDZR7FHCdL85HX024yoKJ8mEb2 glnJ2dVswkR0DMto1448uYCItc= Received: (qmail 9134 invoked by alias); 5 Jun 2014 14:11:04 -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 9121 invoked by uid 89); 5 Jun 2014 14:11:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f47.google.com Received: from mail-qg0-f47.google.com (HELO mail-qg0-f47.google.com) (209.85.192.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 05 Jun 2014 14:10:48 +0000 Received: by mail-qg0-f47.google.com with SMTP id j107so1621519qga.20 for ; Thu, 05 Jun 2014 07:10:46 -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:date:message-id:subject:from:to:cc :content-type; bh=pNs+6PkBIat7fKVzZeln2kloc2TDqDx0kPE9/odwNKU=; b=IEVZRkdZ4y6S00XZ6UgGRXgsc4KPWeIVejY0jgNkz3CUnd/p+Ag4o7kHZKwIhRzbCl rI6EsbBKMGUFWgZ+TtsWjBBD2dNmi7pAd2YXo3pezlCQRVv0RAIR11QUvaZgu3zgy5Xm 4yG5wacwkZqP10gB/8jQZAfJP9I3/Ew4SB4i/MuJycSzsvANRKdXd4HTklUGoDxW7NPe aocIs4Kk5DuK6dVXU+35M/fqoGYg80VNn28ThYC3q4zZuCm+LYdGI204SPSYjUclDkrp P1ROFMrjxgcdepFBi3/ubtKm7qesJtHaA/oU62i1IEcYaNwwsp1jmW4ktLUg0AwSdlWt v3hA== X-Gm-Message-State: ALoCoQnwNR3iA9Pc2Kx6vPQlflVUTVMm1ns6Jd6D5ueBq4/gSfnRT8rYe9tT1OzJvqw9UQBIvoxS MIME-Version: 1.0 X-Received: by 10.229.106.7 with SMTP id v7mr82149533qco.21.1401977446501; Thu, 05 Jun 2014 07:10:46 -0700 (PDT) Received: by 10.229.208.67 with HTTP; Thu, 5 Jun 2014 07:10:46 -0700 (PDT) Date: Thu, 5 Jun 2014 07:10:46 -0700 Message-ID: Subject: [Google/4_8] Fix testsuite/gcc.dg/ipa/ipa-sra-6.c From: Teresa Johnson To: "gcc-patches@gcc.gnu.org" Cc: David Li , Paul Pluzhnikov X-IsSubscribed: yes I just committed the following patch to google/4_8 as 211279. This fixes a test failure with my backport of tree-sra fix r211180 from trunk. It turns out that the bug I fixed affected this test case, but because the dumping format is slightly different between google/4_8 and both google/4_9 and trunk, it didn't show up as a test failure for either google/4_9 or trunk. Essentially, after my fix, both in google/4_8 and google/4_9 (and presumably trunk), I am getting more output in the eipa_sra dump output. Looks like we in fact were previously not properly updating a recursive call due to this same issue that I was fixing, although it didn't manifest as an ICE like in the case I fixed. With the fix, we now properly update a recursive call being optimized by SRA. The test case is expecting to see exactly one occurrence of "foo " in the dump output. In google/4_8, one of the new dump lines matches because it looks like: Adjusting call (0 -> 2) foo -> foo.isra.0 In google/4_9 and trunk, the additional dump lines don't match because the node's order number is being printed after the name: Adjusting call foo/0 -> foo.isra.0/2 2014-06-05 Teresa Johnson * testsuite/gcc.dg/ipa/ipa-sra-6.c: Update to handle recent tree-sra.c fix. Teresa Index: testsuite/gcc.dg/ipa/ipa-sra-6.c =================================================================== --- testsuite/gcc.dg/ipa/ipa-sra-6.c (revision 210862) +++ testsuite/gcc.dg/ipa/ipa-sra-6.c (working copy) @@ -30,5 +30,5 @@ int main (int argc, char *argv[]) return foo (&cow, 0); } -/* { dg-final { scan-tree-dump-times "foo " 1 "eipa_sra" } } */ +/* { dg-final { scan-tree-dump-times "foo " 2 "eipa_sra" } } */ /* { dg-final { cleanup-tree-dump "eipa_sra" } } */