https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109158
Bug ID: 109158
Summary: arm: errors when mixing
__attribute__((pcs("aapcs-vfp"))) with +nofp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: stammark at gcc dot gnu.org
Target Milestone: ---
I've detected a couple of minor issues when using
__attribute__((pcs("aapcs-vfp"))) in no-fp architectures, resulting in wrong
code or an ICE.
reproducer code:
__attribute__((pcs("aapcs-vfp"))) a(__fp16);
void foo() {
a(0.0);
}
Issue 1: when compiled as `-march=armv8.1-m.main+mve+nofp -mfloat-abi=softfp
-mfp16-format=ieee` we emit an invalid FP instruction `vmov.f16` to put the
immediate into `s0` before returning from the function.
I believe this is a simple case of the `*mov<mode>_vfp_<mode>16`assuming that
all variants are valid with any `TARGET_VFP_FP16INST || TARGET_HAVE_MVE` when
actually the `vmov.f16` cases are only valid with TARGET_VFP_FP16INST, but not
with MVE.
Issue 2: when compiled as `-march=armv8.1-m.main+nofp -mfloat-abi=softfp` (i.e.
no MVE, no FP at all) we ICE with `maximum number of generated reload insns per
insn achieved` -- this class of error also happens with `float` and `double`
types.
IMO this is an invalid configuration and we should be emitting a user error
instead of the ICE, similar to what we do if the user requests -mfloat-abi=hard
without any MVE or FP present:
``` else if (TARGET_HARD_FLOAT_ABI)
{
arm_pcs_default = ARM_PCS_AAPCS_VFP;
if (!bitmap_bit_p (arm_active_target.isa, isa_bit_vfpv2)
&& !bitmap_bit_p (arm_active_target.isa, isa_bit_mve))
error ("%<-mfloat-abi=hard%>: selected architecture lacks an FPU");
}```
