[llvm-dev] fp-contract=fast and pragmas

John McCall via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 25 14:43:49 PDT 2021


On 25 Jun 2021, at 17:30, Kaylor, Andrew wrote:
> Hi everyone,
>
> I've been exploring clang's fp-contract behavior recently, and I see 
> that when '-ffp-contract=fast' is used it can't be overridden with a 
> pragma. I would have regarded this as a bug (and in fact, a bug has 
> been filed https://bugs.llvm.org/show_bug.cgi?id=39679). However, I've 
> found some discussions on the mailing lists that described this as 
> expected behavior.
>
> Last October, Sam Liu added support for a new setting 
> ('fp-contract=fast-honor-pragmas') and updated the clang documentation 
> to reflect the behavior of fp-contract=fast. See 
> https://reviews.llvm.org/D90174. I feel very strongly that this should 
> have been done the other way around -- fp-contract=fast should honor 
> pragmas and if we need an option that doesn't that could be added.
>
> In the above review, John McCall asked what "other compilers" do. 
> Steve Canon showed that GCC doesn't honor the pragma. If I may humbly 
> offer another  "other compiler", ICC (which doesn't distinguish 
> between 'on' and 'fast' for fp-contract) does respect the pragma 
> (https://godbolt.org/z/x5r9WdYb4). I'm not saying that ICC should be 
> treated as a reference implementation over GCC or anything like that, 
> but I am saying that its behavior strikes me as more correct than what 
> GCC or clang currently do.
>
> Thoughts and opinions?

I don’t disagree with you in the abstract, but we consider this a 
GCC-designed feature.  ICC’s value as contrary precedent appears 
especially weak because, as you point out, they don’t really implement 
`-ffp-contract=fast`.

There are plenty of other GCC-designed things that I don’t 
particularly like the design of, but where we nonetheless consider 
ourselves bound by their behavior.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210625/995e892a/attachment.html>


More information about the llvm-dev mailing list