From patchwork Wed Jan 15 17:07:04 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Teresa Johnson X-Patchwork-Id: 311205 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 EC6522C0081 for ; Thu, 16 Jan 2014 04:07:14 +1100 (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=ulNdUy1r0MM+ZzqRLanXUbwxOc40pF52r3Khc4lfSuk ccFU/lJOEfZPE3cy/ipbaZFvoUFEbOC0v0zPrEVQFq50OYG9a1pJHMcZrJ3UHxmo 8MAl60cM8zQ6lt64Qd/z0gUJ7vhI7juNSe4b3ko1XS8VtFWO4CPYC6hLGwsfviDs = 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=yGHZBIEjdCXeSwUBnukOm0wQU7M=; b=LPGYPrB9+qls7jZ/a XFZtc/66wo0Z+2WQURBxzL7pYHfDIyMJ8emYL4uVC1aUpoKai9eEZWAy0LclcbcM FgtWp8Wb/odFf5GjOLRf5A+YuRKdj9f60JGSLBDuBBsY4o3OXKsGOGUtSxUtGWv2 eBCcXJTvR+qw0L0azmnQlzrBeY= Received: (qmail 11099 invoked by alias); 15 Jan 2014 17:07:08 -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 11088 invoked by uid 89); 15 Jan 2014 17:07:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f42.google.com Received: from mail-qa0-f42.google.com (HELO mail-qa0-f42.google.com) (209.85.216.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 15 Jan 2014 17:07:07 +0000 Received: by mail-qa0-f42.google.com with SMTP id k4so1153798qaq.1 for ; Wed, 15 Jan 2014 09:07:05 -0800 (PST) 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=r3zSyP/mpuIhJUCQfuAvxmiZnNGEcESdNBfPVOIUyjQ=; b=GhIzDbrPfwzrzUCOWYl/ObzS/wgpXT5JJP9uHfhzU2gZ/vaXlHzueyhAYNjmFK0toE 1CtGNZ0nI5oMcH1Jx5X5S7YqTGUzTN2uft7hd0Tn9s6/6GOJ4zvsVwDQMt6DBQJppXbC V0bTOxES9KKju6U05Q52o10rQPFxft+ritYuE0+KC2xELUHOMEnbvsbXdMbCYZQHemt5 HMWpnHqLiYh86qHalKMuEahlaHVQzb6kIOUSihv5ngMy6ccX20Vu4RT6DSUYiAFcYp/W Y6sXWhDfz7rsK11A3YMFaPCX5syXMznNC13nb9aVQX1o7p+YAnlSqb89IaXrVnpRodj0 YhHA== X-Gm-Message-State: ALoCoQkAmwXQpm9PevaLbngknvLwmAgOob3w6TLQppyT2SQ0ToPxJNwsuo+QsnU0PUz0fY7Q5RJpXsuc9BcqSEeaFSn61dyXFgJGn92ocL/t7K6J6UCEtiiePBkSoZrq4sOm1T5NZfm3itl0p4vHaCZftxwNmKW7ZlIMk33mF9P7egygDpFJvQcvMcsdSf/diPn3b6gLTOFZKGEscJ08NVw3EUpn0GciRw== MIME-Version: 1.0 X-Received: by 10.224.88.70 with SMTP id z6mr6707227qal.14.1389805625003; Wed, 15 Jan 2014 09:07:05 -0800 (PST) Received: by 10.229.117.65 with HTTP; Wed, 15 Jan 2014 09:07:04 -0800 (PST) Date: Wed, 15 Jan 2014 09:07:04 -0800 Message-ID: Subject: [PATCH] Fix segfault in FRE during SCC value numbering From: Teresa Johnson To: "gcc-patches@gcc.gnu.org" Cc: David Li X-IsSubscribed: yes Handle NULL vdef for call in the case where we have a matching vnresult that has a vdef (it already handles the NULL vdef case when !vnresult). This can happen for promoted indirect calls if the fallback indirect call (which has a vdef) can be proven equivalent to the promoted direct call (which might not have a vdef). This occurred for a case where we had a promoted indirect call, where FRE determined that the promoted direct call and the fall-back indirect call were equivalent (since earlier it determined that the function pointer was always set to that target). The indirect call had been analyzed by visit_reference_op_call first, and had a VDEF. The direct call did not have a VDEF, presumably because it was a leaf function in the same module without any stores. But visit_reference_op_call unconditionally calls set_ssa_val_to when the previous vnresult had a vdef, leading to a seg fault in this case. If we had analyzed the direct call first the failure wouldn't have occurred since the !vnresult case guards the call to set_ssa_val_to with a check for a NULL vdef, and the subsequent handling of the indirect call would also not call set_ssa_val_to since vnresult would have had a null result_vdef. Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk? 2014-01-15 Teresa Johnson * tree-ssa-sccvn.c (visit_reference_op_call): Handle NULL vdef. Index: tree-ssa-sccvn.c =================================================================== --- tree-ssa-sccvn.c (revision 206100) +++ tree-ssa-sccvn.c (working copy) @@ -2792,7 +2792,7 @@ visit_reference_op_call (tree lhs, gimple stmt) if (vnresult) { - if (vnresult->result_vdef) + if (vnresult->result_vdef && vdef) changed |= set_ssa_val_to (vdef, vnresult->result_vdef); if (!vnresult->result && lhs)