Currently the options ‘ffast-math’ and ‘ffp-contract’ are connected.
authorZahira Ammarguellat <zahira.ammarguellat@intel.com>
Mon, 29 Aug 2022 14:18:19 +0000 (10:18 -0400)
committerZahira Ammarguellat <zahira.ammarguellat@intel.com>
Fri, 16 Sep 2022 15:08:41 +0000 (11:08 -0400)
commit1b69ce1208976c71bf7ee3932aa272462c1feb1b
tree2671b75552b14f8c09b57aee42ee3d9b8c3850ef
parent00ce271712d407b5347681c36474b80cfb0033d3
Currently the options ‘ffast-math’ and ‘ffp-contract’ are connected.
When ‘ffast-math’ is set, ffp-contract is altered this way:
-ffast-math/ Ofast -> ffp-contract=fast
-fno-fast-math -> if ffp-contract= fast then ffp-contract=on else
ffp-contract unchanged

This differs from gcc which doesn’t connect the two options.

Connecting these two options in clang, resulted in spurious warnings
when the user combines these two options -ffast-math -fno-fast-math; see
issue https://github.com/llvm/llvm-project/issues/54625.

The issue is that the ‘ffast-math’ option is an on/off flag, but the
‘ffp-contract’ is an on/off/fast flag. So when ‘fno-fast-math’ is used
there is no obvious value for ‘ffp-contract’. What should the value of
ffp-contract be for -ffp-contract=fast -fno-fast-math and -ffast-math
-ffp-contract=fast -fno-fast-math? The current logic sets ffp-contract
back to on in these cases. This doesn’t take into account that the value
of ffp-contract is modified by an explicit ffp-contract` option.
This patch is proposing a set of rules to apply when ffp-contract',
ffast-math and fno-fast-math are combined. These rules would give the
user the expected behavior and no diagnostic would be needed.

See RFC
https://discourse.llvm.org/t/rfc-making-ffast-math-option-unrelated-to-ffp-contract-option/61912
clang/docs/UsersManual.rst
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/ffp-contract-option.c
clang/test/Driver/fp-contract.c [new file with mode: 0644]