spatel added a comment.
In D72675#1827893 <https://reviews.llvm.org/D72675#1827893>, @wristow wrote:
> How to handle this seems like an implementation question. The code here is
> just deciding whether or not we intend to pass "-ffast-math" to cc1 (it isn't
> directly defining `__FAST_MATH__`). If we do pass it to cc1, then
> "clang/lib/Frontend/InitPreprocessor.cpp" will pre-define `__FAST_MATH__`:
>
> if (LangOpts.FastMath)
> Builder.defineMacro("__FAST_MATH__");
>
>
> It seems to me that a straightforward way to deal with this question is to
> make the above test more elaborate (that is, if `LangOpts.FastMath` is set,
> OR whatever the appropriate subset of fast-math switches are set). If we do
> that, we don't need to deal with the "umbrella" aspect of "-ffast-math",
> which gets messy.
>
> Which is to say the approach here can stay the same as it currently is
> (`-ffp-contract=off/on` suppressing the passing of "-ffast-math" to cc1).
> Although the comment about `__FAST_MATH__` here in "Clang.cpp" should be
> changed, if we take this approach.
That sounds fine to me, so could update that comment/this patch.
Let's give this a couple of days after updating to see if anyone else has
feedback though. I'm never exactly sure what our responsibility is with respect
to gcc compatibility.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D72675/new/
https://reviews.llvm.org/D72675
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
