From patchwork Wed Oct 25 17:30:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 830340 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-465109-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Ckq0TYYF"; dkim-atps=neutral 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 3yMccP1bJPz9t38 for ; Thu, 26 Oct 2017 04:31:00 +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:from :to:subject:message-id:date:mime-version:content-type; q=dns; s= default; b=Xgl/SGyD2qwTq6Z7T7UMswlR9EW4K1IY4Vl+m0BaMJAhjdmOtpXZM 9N11KmFDbPKPMdWR6ECeipjKYN75ey65BLKohd8FQuGH88Sz2edvfSKcNC5QcSP6 1l5LZliJSJ/JGfq6cmIu6u81jlRK0uESE+7qFxZ5Ev0H7UzaTC9hiU= 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:from :to:subject:message-id:date:mime-version:content-type; s= default; bh=2bsTRLEgEiBBYUGbwwxAXmfN4bM=; b=Ckq0TYYFLyS9KNt9n1Yq Yxd3bpc50QEgdn8aY/qy7+D+75rT7stAXhnOX1jFp09isstogAJAi4u51tuE9Stc kyPwo8o/Y1GQX6lv3Kov/J4y6sEG93MG0QbtwJdUHnxN7egSNoSBaFHMkxAlyor/ 5Q5B7tRCQ2BR0yTN4yxfn8s= Received: (qmail 63483 invoked by alias); 25 Oct 2017 17:30:49 -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 63470 invoked by uid 89); 25 Oct 2017 17:30:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=keen, smuggle 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; Wed, 25 Oct 2017 17:30:48 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D78B77EABC for ; Wed, 25 Oct 2017 17:30:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D78B77EABC Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-112-30.phx2.redhat.com [10.3.112.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 766127010D for ; Wed, 25 Oct 2017 17:30:46 +0000 (UTC) From: Jeff Law To: gcc-patches Subject: [RFA][PATCH] Don't use wi->info to pass gimple location to array warning callbacks in tree-vrp.c Message-ID: <7afb203c-bf08-713f-069a-44ff3d1e1a12@redhat.com> Date: Wed, 25 Oct 2017 11:30:45 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 X-IsSubscribed: yes The array dereference warnings in tree-vrp.c use the gimple walkers to dig down into gimple statements looking for array accesses. I wasn't keen to convert all the clients of the gimple walkers to C++ classes at this time. And the gimple walkers have a mechanism by which we could pass around a class instance -- they've got an opaque pointer (wi->info). THe pointer is already in use to hold a gimple location. So I initially thought I'd have to instead have it point to a structure that would hold the gimple location and a class instance. However, we can get to the gimple location via other means -- we can just extract it from the gimple statement which is a first class entity within the wi structure. That's all this patch does. That frees up the opaque pointer and in a future patch I can just shove the vr_values class instance into it. Bootstrapped and regression tested on x86_64. OK for the trunk? Jeff ps. Now to figure out a strategy for vrp_valueize, which are the last callbacks that need fixing to allow encapsulation of the vr_values bits. * tree-vrp.c (check_all_array_refs): Do not use wi->info to smuggle gimple statement locations. (check_array_bounds): Corresponding changes. Get the statement's location directly from wi->stmt. diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 2bc485c..9defbce 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -6837,10 +6837,7 @@ check_array_bounds (tree *tp, int *walk_subtree, void *data) if (EXPR_HAS_LOCATION (t)) location = EXPR_LOCATION (t); else - { - location_t *locp = (location_t *) wi->info; - location = *locp; - } + location = gimple_location (wi->stmt); *walk_subtree = TRUE; @@ -6887,9 +6884,6 @@ check_all_array_refs (void) memset (&wi, 0, sizeof (wi)); - location_t loc = gimple_location (stmt); - wi.info = &loc; - walk_gimple_op (gsi_stmt (si), check_array_bounds, &wi);