================
@@ -311,11 +311,15 @@ ARMBaseTargetMachine::getSubtargetImpl(const Function &F)
const {
// function that reside in TargetOptions.
resetTargetOptions(F);
I = std::make_unique<ARMSubtarget>(TargetTriple, CPU, FS, *this, isLittle,
- F.hasMinSize());
+ F.hasMinSize());
if (!I->isThumb() && !I->hasARMOps())
F.getContext().emitError("Function '" + F.getName() + "' uses ARM "
"instructions, but the target does not support ARM mode execution.");
+
+ if (I->isTargetHardFloat() && !I->hasFPRegs())
+ F.getContext().emitError("The hard-float ABI is enabled, but the target "
+ "lacks floating-point registers.");
----------------
chrisnc wrote:
I think you are right. I initially avoided that because one of the values is
`Default` which is meant to defer to the triple, but in the constructor of
`ARMBaseTargetMachine` it sets the internal `Options.FloatABIType` to one or
the other based on the passed in option and the triple, so it should be correct
to just use that. I was testing with things like `--target=arm-none-eabi
-mcpu=cortex-m0 -mfloat-abi=hard` and seeing the error trigger, so something
else in the frontend may be generating a different triple that makes this
"work".
https://github.com/llvm/llvm-project/pull/111334
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
