From patchwork Thu Dec 31 15:40:15 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Palka X-Patchwork-Id: 561898 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 2C32C140BA5 for ; Fri, 1 Jan 2016 02:40:39 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=YuQlgCh7; dkim-atps=neutral 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:cc:subject:date:message-id; q=dns; s=default; b=cZbIh4Nu3y10 k3uHOkclT0pvxy3R4wukS9h4SR9Fc447s7XZBub+QnmpOt2WVYEunn+SGLLHUJTk QfbIX00T7zfik+B+62p+pPa6zVV14ZGaJLf5qD8uRrnP5bdzgogpeu20e8Rlv+dI 4YXM6Q6RfjFVqIuDtrdaqKdDYsU0Ndg= 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:cc:subject:date:message-id; s=default; bh=3Ge2IaOY13UbtFPJVw zbKuHpXdQ=; b=YuQlgCh7Iwp14lOKXUMhyi4E7pxrjb2LmnhmlDMr49nMF/QZNo 9LxbMAohXiJlVxD436Zl3OkFM+ymhDHf1OeTnU4g7XE+gmbUEnnmeFxoAfkST/iE rnoH+6DraieWM7Wkw2XS8o6j+dEXpFXe2alCcLdopIB41Ct256m0WJTtA= Received: (qmail 18054 invoked by alias); 31 Dec 2015 15:40:30 -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 18040 invoked by uid 89); 31 Dec 2015 15:40:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=sk:fdumpt, sk:fdump-t, observing, error_mark_node X-HELO: mail-qg0-f50.google.com Received: from mail-qg0-f50.google.com (HELO mail-qg0-f50.google.com) (209.85.192.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 31 Dec 2015 15:40:28 +0000 Received: by mail-qg0-f50.google.com with SMTP id b35so73357165qge.0 for ; Thu, 31 Dec 2015 07:40:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=ruQRgsB3KsEoq5Df9i6tkWqy2DPwXYHiqVHnHkXj3MA=; b=hbTQ/xLSVVDbVfRXOfwJHppPM76jmFlQEoHvFhUl+w+t6wbIc5g0vUy06/VVaq+t+w AdxMhB/D+4Z+qtRAkuzTFqB1p26In7/mp8Dm9f5SxVmfmguVizQpymIjtwsCM1v3+ASt OTurpcpZ2XGs4KNIpTtTGkQR5heTvWFzRZIDQpIsFSx8Id/twqET1n7LNHqFGFrxQeqC pGSzHdiMIp++fe/FvAeSHUVnWXjRYisDY6CubawCsw86Bu2nfKC0Ea5/HA0ohlk7CPl6 Qfa2L0sxKFYsOLvuv7wGtrmLhDLBrgzf66YGu5VdS1pjTOX3jGN4UxKyf+lteN8li2pH ZMGA== X-Gm-Message-State: ALoCoQkJw0rwc0LavJG0gEVj1l1CpSoBeiDiHMBi83eWj6PiglHp8Bmg6IgNpYZeEiOy52MtPglk6DeWjXwxJSvYGjtDH0i/eg== X-Received: by 10.140.95.119 with SMTP id h110mr27324515qge.105.1451576426161; Thu, 31 Dec 2015 07:40:26 -0800 (PST) Received: from localhost.localdomain (ool-4353a98f.dyn.optonline.net. [67.83.169.143]) by smtp.gmail.com with ESMTPSA id i136sm10861236qhc.42.2015.12.31.07.40.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Dec 2015 07:40:25 -0800 (PST) From: Patrick Palka To: gcc-patches@gcc.gnu.org Cc: jakub@redhat.com, jason@redhat.com, Patrick Palka Subject: [PATCH 1/3] Fix logic bug in Cilk Plus array expansion Date: Thu, 31 Dec 2015 10:40:15 -0500 Message-Id: <1451576417-8710-1-git-send-email-patrick@parcs.ath.cx> The Cilk Plus code may sometimes turn a COND_EXPR into an error_mark_node for no good reason. This can be seen by compiling the test case c-c++-common/cilk-plus/CK/pr60469.c with both gcc and g++ and observing the differences of the -fdump-tree-original dumps: With gcc, we get the following code in the GENERIC dump: finally { _Cilk_sync; D.1897.worker->current_stack_frame = D.1897.call_parent; __cilkrts_pop_frame (&D.1897); if (D.1897.flags != 16777216) { __cilkrts_leave_frame (&D.1897); } } Whereas with g++ we get finally { _Cilk_sync; D.2387.worker->current_stack_frame = D.2387.call_parent; __cilkrts_pop_frame (&D.2387); <<< error >>> } Notice that the COND_EXPR is replaced with an << error >> in the g++ dump. This patch fixes the COND_EXPR handling within Cilk Plus. I think the cause is a simple typo/logic bug. gcc/cp/ChangeLog: * cp-array-notation.c (cp_expand_cond_array_notations): Return error_mark_node only if find_rank failed, not if it was successful. --- gcc/cp/cp-array-notation.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/cp/cp-array-notation.c b/gcc/cp/cp-array-notation.c index 8862af1..3a6d773 100644 --- a/gcc/cp/cp-array-notation.c +++ b/gcc/cp/cp-array-notation.c @@ -807,8 +807,8 @@ cp_expand_cond_array_notations (tree orig_stmt) if (!find_rank (EXPR_LOCATION (cond), cond, cond, true, &cond_rank) || !find_rank (EXPR_LOCATION (yes_expr), yes_expr, yes_expr, true, &yes_rank) - || find_rank (EXPR_LOCATION (no_expr), no_expr, no_expr, true, - &no_rank)) + || !find_rank (EXPR_LOCATION (no_expr), no_expr, no_expr, true, + &no_rank)) return error_mark_node; /* If the condition has a zero rank, then handle array notations in body separately. */