================ @@ -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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
