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

2022-06-29 Thread 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.

2022-06-29 Thread 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,

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

2022-06-29 Thread 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.

2022-06-29 Thread 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

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

2022-06-29 Thread 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

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

2022-06-28 Thread 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.

2022-06-28 Thread 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

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

2022-06-28 Thread 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