Re: [yocto] Issues and questions regarding PowerPC 32-bits e500v2 tuning

[Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>]

----- Original Message -----
> From: "Khem Raj" <raj.khem@gmail.com>
> To: "yocto" <yocto@lists.yoctoproject.org>, "adrian freihofer" <adrian.freihofer@siemens.com>
> Cc: "Elinor Montmasson" <elinor.montmasson@savoirfairelinux.com>
> Sent: Thursday, 22 October, 2026 22:37:25
> Subject: Re: [yocto] Issues and questions regarding PowerPC 32-bits e500v2 tuning

>> On Thu, Oct 22, 2026 at 2:27 AM Adrian Freihofer via [
>> http://lists.yoctoproject.org/ | lists.yoctoproject.org ] <adrian.freihofer= [
>> mailto:siemens.com@lists.yoctoproject.org | siemens.com@lists.yoctoproject.org
>> ] > wrote:

>> Hi Elinor

>> I remember the times when I was working with a MPC5200. Quite a few
>> years ago :-).

>> If you can mix binaries built with different floating point
>> implementations depends on the details of the CPU architecture, at
>> least. We had some discussions related to ARM 32 a few years ago. I
>> just remember that "it depends on the details".

>> With wrynose there is now a TOOLCHAIN variable which can be set to
>> clang globally. But it depends on what you need if a build without gcc
>> is possible or not. For example, there is a patchset which fixes glibc
>> for building with clang (around 50 patches from ARM) somewhere around.
>> With musl it should work as well. Not sure this would allow you to go
>> with clang only for your use case.

>> There are also some discussions with maintaining some LTS branches like
>> dunfell for longer than 4 years unofficially by users who need that.

>> Just some alternative ideas.

> GCC dropped SPE in 9.1 timeframe, so soft-float is the only option. however
> another
> issue is that glibc also dropped it starting 2.30 release, so only option is
> using musl since
> it does support single float (-sf) abi on ppc.

Yes good point thanks

> I added 0019-Re-introduce-spe-commandline-options.patch, back then to keep
> qemuppc working, it simply made gcc to accept -mabi=spe -mspe
> -mfloat-gprs=double
> which are passed from tune-ppce500v2.inc, it then ignores them and falls back to
> classic hard-float FPU instructions, e500v2 has no classic FPU, so the binaries
> crash with SIGILL
> is no surprise. tune-ppce500.inc has the same problem. It has the same spe
> feature with
> -mfloat-gprs=single.
> a performance-compromised fix is to make these tunes use fpu-soft and drop spe

> Using clang is not going to work out of box either, while it does support SPE it
> does have
> some things to take care of e.g. -mfloat-gprs=double is not supported.

Do you know if an equivalent option or options exist with clang for this?
Or if it just not relevant with clang?

> it also will reject
> linux-gnuspe and linux-muslspe triples that OE uses. it needs something like
> powerpcspe-*-*
> or patching llvm sources to do what OE has done in past.

> Some recipes with GCC + fpu-soft, the rest with clang + SPE combo has an ABI
> problem.
> Ordinary calls and returns are compatible, since both pass doubles in pairs of
> general registers.
> The trouble is mixing the two in one process: a libgcc built for soft-float sets
> the FP environment
> differently from SPE code.

I see
So does it means that for a given application/process, the floating point
support (soft or SPE here) must be the same for the runtime used,
the dynamic libraries used and the application itself,
to avoid any ABI compatibility problem?

In that case, I suppose two compiler runtime may be installed,
compiled with their respective compiler?
* libgcc for GCC + fpu-soft compiled programs
* llvm runtime for clang + SPE compiled programs

But then the ABI compatibility constraint will create complexity for
compiling and installing shared libraries.

> Dunfell is not a way to keep SPE; only warrior or older is.


Best regards,
Elinor Montmasson