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