Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Sep 2016 15:38:49 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
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>

next in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9173A73E-CA3B-4F55-947D-4003FF42DDCE>