Received: by 10.223.185.116 with SMTP id b49csp3888324wrg; Mon, 26 Feb 2018 07:43:40 -0800 (PST) X-Google-Smtp-Source: AH8x225MvT2YQAMNEx12aVhU7qlciIdwk50MvNLuDc+nXf3DT+JG6EEAV6JTl9WSi5JA2uYFOXf6 X-Received: by 10.98.49.7 with SMTP id x7mr11043533pfx.101.1519659820670; Mon, 26 Feb 2018 07:43:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519659820; cv=none; d=google.com; s=arc-20160816; b=ItsX3bEpH9uQ3p7s0mO5ISgU6Rno95sd05mwRCcv+Wm8m9Ug1k0tJ8h8Qx2bYRkgPu sXnTQrArX6HyUUQjQBCC/Z4NAvsWTNzPISYASpBVJibncTJrhMmAvhBz+5bFFTCC+97l MJ0CBYtERv4lIG3v/DilbkPBTK2LMAOxdz5GgnTziT4yx0zj1kYo+yPtuFPPVD/qSwIz lDBlKdrNu9Ao2AbdcYh1Pj467RJzTyNW8uE/1a4FLUf78aT/eGM1N7+jOpikwZuJ8WrD cGA9YuF1M1hWpM1FiC472JdRuvMdtwIimYCoHIF8AbQ53jgIERY1CJHWtTXKxfw2IVWn +eug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:cc:from:date:content-transfer-encoding:mime-version :subject:to:arc-authentication-results; bh=XgdcXpzP7GWvm/w4nwmIqtemtt7Y5MLBqRHPjBefai0=; b=ebXdCRzctdOCUZJvBmj1pZ4jfjjqlDk/taJW2m7q4ull0l8LtS/P76gy+l/ygQlfko LBVWwwd+7/O2EnF9+RyFCtEmSYKgEXDwFEi9tq/koc8t6CUeHj+EZF2JZsU6Dw7vfurf 1V1dJEpjCf5ZFRIOSzQPGGGUfbHiMdVNTbcXyHQ9bCBOe9+1HvvptpzYCZ5kgIYKzND+ 149DKDyJeed4/AGZaYLqoubDzcIM9mckux7Eqnqy8erMmXbwg/+W4oGlCIuF5JzeEqOZ xT6c3CqAOd3/3AbG1h5YtAu9XGohaA8pnDXshAY+fdZyX2uZ5h/Asgvr/qwWqDAla2gx T14w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c10si2983012pgf.582.2018.02.26.07.43.26; Mon, 26 Feb 2018 07:43:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752135AbeBZPmE (ORCPT + 99 others); Mon, 26 Feb 2018 10:42:04 -0500 Received: from uruz.whitequark.org ([188.166.218.19]:32916 "EHLO uruz.whitequark.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752097AbeBZPmB (ORCPT ); Mon, 26 Feb 2018 10:42:01 -0500 X-Greylist: delayed 600 seconds by postgrey-1.27 at vger.kernel.org; Mon, 26 Feb 2018 10:41:59 EST Received: by uruz.whitequark.org (Postfix, from userid 1002) id 6E9AC230A1; Mon, 26 Feb 2018 15:24:25 +0000 (UTC) To: Philipp Wagner Subject: Re: [OpenRISC] Removing architectures without upstream gcc support X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 26 Feb 2018 15:24:25 +0000 From: whitequark Cc: Arnd Bergmann , linux-arch , Linux Kernel Mailing List , Jonas Bonn , Chen Liqin , "open list:QUALCOMM HEXAGON..." , Richard Kuo , David Howells , openrisc@lists.librecores.org, Lennox Wu , James Hogan , Guan Xuetao , "open list:METAG ARCHITECTURE" , Guenter Roeck , Al Viro In-Reply-To: <57602e7e-a9c6-3480-7e99-7d274e836ed6@philipp-wagner.com> References: <155284c9-7fd4-2f2c-0216-1c43622f88c3@philipp-wagner.com> <57602e7e-a9c6-3480-7e99-7d274e836ed6@philipp-wagner.com> Message-ID: <9dda26a68c1174933e456227efb6ae01@whitequark.org> X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/1.2.3 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-02-26 12:10, Philipp Wagner wrote: > Actually the LLVM port of or1k isn't upstream either. CCing > whitequark, who might know more about the (non-)plans of getting the > backend upstream. I also don't know of anyone having tried to build > the openrisc kernel with LLVM, would certainly be an interesting thing > to try. I keep the OR1K backend up-to-date and generally in good shape (e.g. I've got exception handling work and added all missing instructions to the internal assembler) but upstreaming it is many weeks of work that I personally cannot spare, and the LLVM community requests that those who upstream backends maintain buildbots running hardware tests indefinitely, which I personally cannot afford. -- whitequark