From owner-freebsd-ppc@freebsd.org Fri Sep 9 18:46:05 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7F54BD4929 for ; Fri, 9 Sep 2016 18:46:05 +0000 (UTC) (envelope-from kristof@swissmail.org) Received: from smtp.swissmail.org (smtpout.swissmail.org [212.25.22.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74E6BFF0 for ; Fri, 9 Sep 2016 18:46:04 +0000 (UTC) (envelope-from kristof@swissmail.org) Received: from vm-mailout2.vm.swissmail.org (vm-mailout2.vm.swissmail.org [212.25.22.135]) by smtp.swissmail.org (Postfix) with ESMTPS id B92D280818 for ; Fri, 9 Sep 2016 20:40:50 +0200 (CEST) Received: from vm-pemfos1.intra.swissmail.org (unknown [192.168.173.54]) by vm-mailout2.vm.swissmail.org (Postfix) with ESMTP id BFB179FBA5 for ; Fri, 9 Sep 2016 20:46:02 +0200 (CEST) Received: from vm-pemfos1.intra.swissmail.org (localhost [127.0.0.1]) by localhost (Postfix-local-10025) with ESMTP id B1800A81C9 for ; Fri, 9 Sep 2016 20:46:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (PEmFoS/1619.25015.a1); Fri, 9 Sep 2016 20:46:02 +0200 (CEST) X-Pemfos-Policyd: accepted (IwPqEwJoiwspJin0YDGpSgwBV3Q3QxG+HR8/I185DTogX3ovMRAIoAcfBSYXXiZh) Subject: Re: From llvm: Fwd: [Bug 26519] Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result) [fixed in llvm -r280705] To: freebsd-ppc@freebsd.org References: <6EA51424-C360-4604-B2D5-06C6762600A9@dsl-only.net> From: Krzysztof Parzyszek Message-ID: <74556e62-cc12-a4c7-53f4-0be7ec01163f@swissmail.org> Date: Fri, 9 Sep 2016 13:45:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6EA51424-C360-4604-B2D5-06C6762600A9@dsl-only.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at vm-mailout2 X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 18:46:05 -0000 On 9/8/2016 8:02 PM, Mark Millard wrote: > > Interestingly http://compiler-rt.llvm.org says (mentioning powerpc64 explicitly): > > [Quoting the web site this time.] > >> Platform Support >> >> builtins is known to work on the following platforms: >> >> • Machine Architectures: i386, X86-64, SPARC64, ARM, PowerPC, PowerPC 64. >> • OS: AuroraUX, DragonFlyBSD, FreeBSD, NetBSD, Linux, Darwin. > > If true for all builtins (libgcc like) for powerpc64 then I'm not sure why there is the code: > > [Quoting from https://reviews.llvm.org/D13351 and its cfe/trunk/lib/Driver/Tools.cpp material this time.] > >> ppc::FloatABI FloatABI = ppc::getPPCFloatABI(D, Args); >> if (FloatABI == ppc::FloatABI::Soft && >> !(Triple.getArch() == llvm::Triple::ppc64 || >> Triple.getArch() == llvm::Triple::ppc64le)) >> Features.push_back("+soft-float"); >> else if (FloatABI == ppc::FloatABI::Soft && >> (Triple.getArch() == llvm::Triple::ppc64 || >> Triple.getArch() == llvm::Triple::ppc64le)) >> D.Diag(diag::err_drv_invalid_mfloat_abi) >> << "soft float is not supported for ppc64"; > > The above reports that "soft float is not supported for ppc64". This notice seems to be global for clang powerpc64: in no way FreeBSD specific. > > May be the view is that no floating point builtins ever apply to powerpc64 (but they do for powerpc (32))? I think the reasoning was that all powerpc64 cores do contain floating-point units (and that the 64-bit part wasn't tried/tested/etc). I have looked at compiler-rt and it does have support for all floating-point operations (although it seems to only do rounding-to-nearest). On a somewhat related note---the kernel does have some sort of an FPU emulation---do you know what it's for and how it's used? It does make more sense to use compiler-supported library though, after all it's the compiler generating calls to it. -Krzysztof