From owner-freebsd-ppc@freebsd.org Sat Sep 10 05:45:33 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 7EE63BD2669 for ; Sat, 10 Sep 2016 05:45:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-185.reflexion.net [208.70.211.185]) (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 47A526EF for ; Sat, 10 Sep 2016 05:45:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10046 invoked from network); 9 Sep 2016 22:38:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Sep 2016 22:38:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Fri, 09 Sep 2016 18:38:55 -0400 (EDT) Received: (qmail 12542 invoked from network); 9 Sep 2016 22:38:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Sep 2016 22:38:55 -0000 Received: from [192.168.0.104] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 519DEEC8A89 for ; Fri, 9 Sep 2016 15:38:50 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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] Message-Id: <9173A73E-CA3B-4F55-947D-4003FF42DDCE@dsl-only.net> Date: Fri, 9 Sep 2016 15:38:49 -0700 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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: Sat, 10 Sep 2016 05:45:33 -0000 Krzysztof Parzyszek kristof at swissmail.org wrote on Fri Sep 9 18:46:05 = UTC 2016 > 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: > >> > >> =E2=80=A2 Machine Architectures: i386, X86-64, SPARC64, ARM, = PowerPC, PowerPC 64. > >> =E2=80=A2 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 =3D ppc::getPPCFloatABI(D, Args); > >> if (FloatABI =3D=3D ppc::FloatABI::Soft && > >> !(Triple.getArch() =3D=3D llvm::Triple::ppc64 || > >> Triple.getArch() =3D=3D llvm::Triple::ppc64le)) > >> Features.push_back("+soft-float"); > >> else if (FloatABI =3D=3D ppc::FloatABI::Soft && > >> (Triple.getArch() =3D=3D llvm::Triple::ppc64 || > >> Triple.getArch() =3D=3D 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))? >=20 > I think the reasoning was that all powerpc64 cores do contain=20 > floating-point units (and that the 64-bit part wasn't = tried/tested/etc). >=20 > I have looked at compiler-rt and it does have support for all=20 > floating-point operations (although it seems to only do=20 > rounding-to-nearest). >=20 > On a somewhat related note---the kernel does have some sort of an FPU=20= > emulation---do you know what it's for and how it's used? It does make=20= > more sense to use compiler-supported library though, after all it's = the=20 > compiler generating calls to it. >=20 > -Krzysztof "the kernel does have some sort of an FPU emulation": care to point me = at what you are referring to? (Just curiosity.) The kernel would context = switch user processes with floating-point save/restore activity for = processes that need such. That is different than kernel-internal context = changes as I understand. But even without the kernel involved: libstand in buildworld requires = soft-float --and stops buildworld for powerpc64. If powerpc64 software floating-point builtins in compiler-rt were not = tested for powerpc64 then I find the claim: > >> builtins is known to work on the following platforms: > >> > >> =E2=80=A2 Machine Architectures: i386, X86-64, SPARC64, ARM, = PowerPC, PowerPC 64. > >> =E2=80=A2 OS: AuroraUX, DragonFlyBSD, FreeBSD, NetBSD, Linux, = Darwin. odd. That would suggest that those builtins are viewed as no applying to = powerpc64 (because there is always a floating point unit?). If the soft-float built-ins do apply to powerpc64, may be the same sort = of things could be done for powerpc64 that were done for powerpc to = enable using them. (compiler-rt had such code long before clang enabled = soft-float for powerpc from what I see for dates.) But the two .S files restFP.S and saveFP.S in = compiler-rt/lib/builtins/ppc/ might need to be checked if they allow for = a powerpc64 targeted use. There is no conditional code at all, nothing = for any powerpc64 specifics. powerpc and powerpc64 have distinct API's = overall and so might not fully match for this. (And FreeBSD's chosen = ABIs are not the only ones around.) Those .S files do seem to assume that specific floating point registers = exist. May be they are only used for hard-float, not soft-float? (Again: = FreeBSD might use libgcc content instead of compiler-rt for powerpc64 = and/or powerpc.) =3D=3D=3D Mark Millard markmi at dsl-only.net