Received: by 10.223.185.116 with SMTP id b49csp3710339wrg; Mon, 26 Feb 2018 04:53:12 -0800 (PST) X-Google-Smtp-Source: AH8x224OJgc3mNu9FLCZx1UNsb8SigaNBrX/slp6WqiHcDDkIUDRn3CejM04j81XiGJKX2xnH/g/ X-Received: by 2002:a17:902:428:: with SMTP id 37-v6mr10401448ple.63.1519649592760; Mon, 26 Feb 2018 04:53:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519649592; cv=none; d=google.com; s=arc-20160816; b=m9VskJ+dIYjY5g4PRD/DOFY3NVa9aFIiKJ7H/w7IunjBhtzBg1jltF2sLaQaByGlir Jf+cAOwAKNWisfB/CrOtVr1HGbgTUzbrPXAZxh7ALRy9DuhVZBasXv0G7Rc8lVIt/2Xs NAkZ6d05HD1B+/gzs+z8GhnAGUEV4AI/MG2Sx8xckhuUZp7abtN3ivwwEnlbi0U3a9jz foBYGwvJRhdiCV3s36gjyDiw/BCOSCd7+qK7/LUBph3UyFcznS/0YwQShnJ6wF4AqGZ2 wWUI/MhGr1CuSwmiCM2KJixQtVV3RfDRIyZbSxGL7Yr0QfUx07bKzxfB5SdRcdKCBXST fkAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Dq+GKsGV6u43yKQEf5yZys3ZmUybhqLsaBSbfz+pvTE=; b=WFG/2FpHE3JVpQAJxU18auFxrvou9R9jXhrzq59kxRrOZ2v2Tuta+tob/Cxppzr+Mt NL9KXOF9ORWYnv9eILalNgB2uuLmgd/7mspqhnOENf63moCoc4uM4C42Jf+VLe6eZjsK TkyT7jQcUH89ZHzJd5xHQ+FcpoDLoohjkKvOiO9OPPPbhkGhZVct4/od6Sp2u/esqjsz pBOPx4WADwg7PG4zREkC/fJb3cEZMvoUw6DketICobv8fqNOarR/S6IgWl7guzaBFkY9 rQovbN2p52+5yNA4sEqLQ44X4g4al7gK6Y40puAIZ88p1/N+VGHXnZhtalaiDC8bloa+ /lGA== 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 v6-v6si6924788plk.577.2018.02.26.04.52.58; Mon, 26 Feb 2018 04:53:12 -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 S1752722AbeBZMfV (ORCPT + 99 others); Mon, 26 Feb 2018 07:35:21 -0500 Received: from smtprelay08.ispgateway.de ([134.119.228.107]:3642 "EHLO smtprelay08.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752420AbeBZMfT (ORCPT ); Mon, 26 Feb 2018 07:35:19 -0500 X-Greylist: delayed 1467 seconds by postgrey-1.27 at vger.kernel.org; Mon, 26 Feb 2018 07:35:18 EST Received: from [129.187.155.160] by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eqHcK-0005s1-2U; Mon, 26 Feb 2018 13:10:52 +0100 Subject: Re: [OpenRISC] Removing architectures without upstream gcc support To: Arnd Bergmann Cc: 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 , whitequark@whitequark.org References: <155284c9-7fd4-2f2c-0216-1c43622f88c3@philipp-wagner.com> From: Philipp Wagner Message-ID: <57602e7e-a9c6-3480-7e99-7d274e836ed6@philipp-wagner.com> Date: Mon, 26 Feb 2018 13:10:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Df-Sender: bGlzdHNAcGhpbGlwcC13YWduZXIuY29t Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/26/2018 09:00 AM, Arnd Bergmann wrote: > On Sun, Feb 25, 2018 at 4:43 PM, Philipp Wagner > wrote: >> Am 22.02.2018 um 16:45 schrieb Arnd Bergmann: >>> While building the cross-toolchains, I noticed that overall, we can build almost >>> all linux target architectures with upstream binutils and gcc these days, >>> however there are still some exceptions, and I'd like to find out if anyone >>> has objections to removing the ones that do not have upstream support. >>> This are the four architectures I found: >>> [...] >>> * OpenRISC is a RISC architecture with a free license and an >>> active community. It seems to have lost a bit of steam after RISC-V >>> is rapidly taking over that niche, but there are chips out there and >>> the design isn't going away. Listing it here for completeness only >>> because there is no upstream gcc port yet, but this will hopefully >>> change in the future based on >>> https://lists.librecores.org/pipermail/openrisc/2018-January/000958.html >>> and I had no problems locating the gcc-7.x tree for building my >>> toolchains. The port is actively being maintained. >> >> It's mostly mentioned in the mailing list thread you linked to, but just >> for completeness in this thread: >> >> The OpenRISC GCC port is maintained and regularly updated to newer GCC >> versions. It is not, however, upstreamed to the FSF due to a single >> missing FSF copyright assignment from a developer who has written large >> parts of the initial port. All code which has copyright assignments in >> place (binutils, GDB, etc.) has been upstreamed lately. >> >> For GCC, Stafford Horne is actively working on rewriting the parts which >> we don't have the FSF copyright assignment for (and unless something >> very surprising happens, won't get). [If anyone wants to help, there's >> GSoC project for it as well: >> https://fossi-foundation.org/gsoc18-ideas#openrisc-gcc-port] >> >> So I'd be very sad if the openrisc port gets dropped from Linux upstream. > > Yes, definitely. What I was really trying to say here is I consider openrisc > an obvious exception to the 'no more ports without upstream gcc' rule > because of the above. > > On a related note, has anyone successfully built an openrisc kernel with > llvm/clang? As we discussed for arch/hexagon/, that architecture is unlikely > to ever get an upstream gcc port, but like openrisc does have an upstream > llvm port and they actually use that. 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 know that x86 and arm64 mostly work with llvm, arm32 works in some of > the more common configurations at least (not big-endian or older CPUs > though) and some others probably work as well. I have already build both > gcc-5.5 and gcc-7.3 for openrisc and uploaded those to > https://www.kernel.org/pub/tools/crosstool/files/bin/, but if llvm works as > well, that could be one more reason to try to build a working set of > clang based cross toolchains. Philipp