[clang] [llvm] [ARM] Emit an error when the hard-float ABI is enabled but can't be used. (PR #111334)

[Peter Smith via cfe-commits]

================
@@ -16,7 +16,7 @@
 
 // RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s -flto=thin -c -o %t.call_thin.bc -DCALL_LIB
 // RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s -flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN: llvm-lto2 run -o %t.lto_thin -save-temps %t.call_thin.bc %t.define_thin.bc \
+// RUN: llvm-lto2 run --mcpu=cortex-m33 --float-abi=hard -o %t.lto_thin -save-temps %t.call_thin.bc %t.define_thin.bc \
----------------
smithp35 wrote:

I think that would be a good way forward. That would help reduce the chances of this breaking some existing projects.

That would then leave us with the debate about front-end and back-end error messages. I've been thinking about how to get past the differences of opinion here. My thoughts so far:
* Make the clang warning an error (to match GCC) and make sure it triggers for the target and the -mfloat-abi=hard case. Then clang users will see a front-end error and shouldn't see the backend error unless they've messed about behind the compilers back with target attributes. Other front-ends can choose their own policy.
* Make the back-end error opt-in, with clang opting out and retaining the existing clang warning. That retains the existing behaviour for clang. I personally would prefer clang/gcc to behave the same way and give an error message.

While I think that either of those would take care of user facing concerns, there's a possible objection of code complexity, but I'd have to leave that in the hands of the code-owners.

https://github.com/llvm/llvm-project/pull/111334