[PATCH] libphobos: RISC-V: Fix soft-float build errors with IEEE exception flags

[Iain Buclaw]

On Thu, 2 May 2019 at 22:35, Jim Wilson <jimw@sifive.com> wrote:
>
> On Wed, May 1, 2019 at 6:14 PM Maciej Rozycki <macro@wdc.com> wrote:
> > within inline assembly, to access IEEE exception flags.  The use of
> > these instructions is not allowed when building for a soft-float ABI.
>
> Technically it is an architecture issue not an ABI issue.  If you
> compile for -march=rv32imac -mabi=ilp32 then you can't use FP
> instructions.  If you compile for -march=rv32imafc -mabi=ilp32 then
> you can use FP instructions, but we don't use FP regs for argument
> passing.  This is similar to the distinction that ARM makes between
> the soft and softfp ABIs.  The RISC-V newlib port for instance checks
> __riscv_flen to decide whether to use FP instructions.  The predefined
> macro __riscv_flen is set to 0 if the target architecture doesn't have
> FP registers.  So the choice of using FP instructions depends on the
> target architecture, not the target ABI.
>
> I see that gcc/config/riscv/riscv-d.c has
>   if (TARGET_HARD_FLOAT)
>     d_add_builtin_version ("D_HardFloat");
>   else
>     d_add_builtin_version ("D_SoftFloat");
> so the patch looks OK, because this is checking the architecture not the ABI.
>
> But the arm/arm-d.c file is defining 3 ARM_* macros for FP support,
> and long term we might need something similar in the RISC-V D port for
> full RISC-V support.  Through for RISC-V it is probably better to have
> separate macros for architecture FP support and ABI FP support, each
> of which can have 3 values, because you can have for instance an arch
> with 64-bit FP support, but an ABI with only 32-bit FP support, and so
> worst case we might need to track the arch/abi FP support separately.
> This is how it works in the C front end.  We have __riscv_flen which
> can be 0, 4, or 8 and which indicates the hardware FP register size in
> bytes.  And we have __riscv_float_abi_soft, __riscv_float_abi_single,
> and __riscv_float_abi_double, only one of which is defined, which
> indicates the max size of arguments that can be passed in FP
> registers.
>

A future version of the D language adds a new feature to cover this,
__traits(getTargetInfo,"key").

https://dlang.org/spec/traits.html#getTargetInfo

I have a slight inclination to push the information there instead of
adding additional RISCV_* version conditions, particularly as the
result returned can be any kind of value, which has a slight leverage
over version conditions which are just boolean true/false.

-- 
Iain