[PATCH] D12633: Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] targets

[Richard Barton via cfe-commits]

richard.barton.arm added a comment.

In the overall approach, whilst this is the pragmatic approach to get the job done, it clearly takes liberties with the definition of LangOpt as this your new flag is most certainly a CodeGenOpt rather than a LangOpt. I'd like to see what the others say as I don't see a better solution.


================
Comment at: lib/Frontend/CompilerInvocation.cpp:1711
@@ -1710,1 +1710,3 @@
       Args.hasArg(OPT_cl_fast_relaxed_math);
+  Opts.UnsafeFPMath = Args.hasArg(OPT_menable_unsafe_fp_math) ||
+                      Args.hasArg(OPT_cl_unsafe_math_optimizations) ||
----------------
labrinea wrote:
> richard.barton.arm wrote:
> > What happens if I do -menable-unsafe-fp-math then -mno-enable-unsafe-fp-math? I don't think you have enough regression tests.
> Well there is no such flag (-mno-enable-unsafe-fp-math) but probably what you want to say is that the order of the front-end flags matters. In **llvm/tools/clang/test/Driver/fast-math.c** there are tests checking whether "-menable-unsafe-fp-math" is correctly set depending on the order of the front-end flags. I could modify my tests so that they pass cc1 flags. Then we would be checking if _ARM_FP_FAST gets defined in the presence of "-menable-unsafe-fp-math". Would that be preferable?
Ok - I did not realise that by this point in the code we know this has been taken care of. If that argument processing is already covered by tests then there is no need to add more and I retract my suggestion.


http://reviews.llvm.org/D12633