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]

[Mark Millard]

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:
> >>
> >> 	• 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

"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:
> >>
> >> 	• Machine Architectures: i386, X86-64, SPARC64, ARM, PowerPC, PowerPC 64.
> >> 	• 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.)

===
Mark Millard
markmi at dsl-only.net