[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #8 from John McCall  ---
Oh, that's what I get for having two different draft standards open at once. 
Thanks.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #7 from joseph at codesourcery dot com  ---
FLT_EVAL_METHOD of 0 gives _Float16 excess precision ("evaluate all 
operations and constants, whose semantic type comprises a set of values 
that is a strict subset of the values of float, to the range and precision 
of float; evaluate all other operations and constants to the range and 
precision of the semantic type").  See the -fpermitted-flt-eval-methods= 
option that's used to control whether FLT_EVAL_METHOD may be defined to a 
value such as 16 that's not part of C11.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #6 from John McCall  ---
Ah, I can see how the FLT_EVAL_METHOD schema gives us a unifying scheme, thank
you.  Just to be clear, though, the actual value of FLT_EVAL_METHOD in that
mode should be 0, correct?

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #5 from joseph at codesourcery dot com  ---
The idea with "16" is to say that's the exact FLT_EVAL_METHOD value 
(defined in C23 Annex H) whose semantics should be followed.  It would 
affect float/double promotion on i386 as well (the back end gives an error 
that the combination of that option with -mfpmath=387 is unsupported).

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #4 from John McCall  ---
Ah, thank you, we weren't aware of -fexcess-precision=16.  If that's the
precedent, we can certainly follow it.

The idea around "16" was to make it clear that this just affects _Float16?  If
the option were named -fexcess-precision=none, then I suppose someone who had
started passing it years ago to prevent float/double promotion on i386 would
now unintentionally be affected by it for _Float16.  Put another way, there's
an implicit assumption in the re-use of a single option that targets will have
a linear history of support for more floating point types, such that there's
only one kind of emulation in use at once.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #3 from Hongtao.liu  ---
we're using -fexcess-precision=16 to force operation-by-operation translation
when  AVX512-FP16 is not available.

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576493.html

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #2 from joseph at codesourcery dot com  ---
"none" was something I mentioned as a possible future argument when 
originally posting -fexcess-precision 
.  I 
still think it's the appropriate name for that case.

(Doing +-*/ operations on float and then immediately converting back to 
_Float16 has exactly the same semantics as direct _Float16 arithmetic; 
float has sufficient precision that no double rounding issues arise; that 
doesn't apply to fma, however.  The effect of excess precision is that 
e.g. in "a + b + c", the value of a + b with the range and precision of 
float is what gets added to c; there's no intermediate truncation of a + b 
to _Float16.  But (_Float16)(a + b) + c would have such a truncation, 
because casts and conversion as if by assignment remove excess range and 
precision.)

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

John McCall  changed:

   What|Removed |Added

 CC||rjmccall at gmail dot com

--- Comment #1 from John McCall  ---
To clarify one point: Clang plans to use excess precision arithmetic as the
default for _Float16 when AVX512-FP16 isn't available, following the C
standard's rules, i.e. `-fexcess-precision=standard`.  We'd like to offer users
a way to disable this and force operation-by-operation translation, but as far
as we can tell, there isn't a way to request this in GCC today.  It feels like
`-fexcess-precision=none` (or some similar spelling) would be the most
appropriate way to do this, since of course this conflicts with other values of
`-fexcess-precision`.

Since GCC originated `-fexcess-precision`, we're trying to being neighborly and
ask whether you have a problem with this extension.