From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28886 invoked by alias); 2 Dec 2016 21:35:05 -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 28877 invoked by uid 89); 2 Dec 2016 21:35:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=speak, hides, raised, relay 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, 02 Dec 2016 21:35:04 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 F16E37AE81; Fri, 2 Dec 2016 21:35:02 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-36.rdu2.redhat.com [10.10.116.36]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2LZ1oC030020; Fri, 2 Dec 2016 16:35:02 -0500 Subject: Re: [PATCH] Fix PR78306 To: Richard Biener , Andrew Senkevich References: <7b587730-b3cc-6558-f53a-06f53074de81@redhat.com> <7e9c05f1-a4d6-2a79-7c03-0219c90cf134@redhat.com> Cc: GCC Patches From: Jeff Law Message-ID: Date: Fri, 02 Dec 2016 21:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-7; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00251.txt.bz2 On 11/30/2016 07:18 AM, Richard Biener wrote: > > so progess on the OMP front hides regressions elsewhere. The patch > that started this thread does not have any effect on the conformance > testsuite result. > > That makes it even more obvious that it is a) unmaintained, b) probably > not used widely as those ICEs have not been reported as bugs > > Let's deprecate Cilk+ if no maintainer steps up until 7.1 is released. > Gerald, can you relay that to the SC? I've raised the issue with the steering committee; I will also speak with Intel about the possibility of them providing resources to maintain this code. jeff