Re: [PATCH] Document -fexcess-precision=16.

[Joseph Myers <josmyers@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

On Tue, 19 Mar 2024, Hongtao Liu wrote:

> On Tue, Mar 19, 2024 at 12:16 AM Joseph Myers <josmyers@redhat.com> wrote:
> >
> > On Mon, 18 Mar 2024, liuhongt wrote:
> >
> > > +If @option{-fexcess-precision=16} is specified, casts and assignments of
> > > +@code{_Float16} and @code{bfloat16_t} cause value to be rounded to their
> > > +semantic types if they're supported by the target.
> >
> > Isn't that option about rounding results of all operations, whether or not
> > a cast or assignment is involved?  That's certainly what the brief mention
> > of this option in extend.texi says, and fits the intent that
> > -fexcess-precision=16 corresponds to FLT_EVAL_METHOD == 16.
> Yes, how about this.
> 
> 
> +If @option{-fexcess-precision=16} is specified, each operation of
> +@code{_Float16} and @code{bfloat16_t} causes value to be rounded to their
> +semantic types if they're supported by the target.

I'm sure sure it's quite right to say the operation causes the value to be 
rounded, considering it's results not arguments that are rounded, and from 
the user perspective the rounding is an implementation detail, it's just 
computing the results in the semantic type.  So maybe more like:

  If @option{-fexcess-precision=16} is specified, constants and the
  results of expressions with types @code{_Float16} and @code{__bf16}
  are computed without excess precision.

(Also, I've suggested there to use the built-in type name __bf16; the name 
__bfloat16 from avx512bf16vlintrin.h would also be a possibility.  As far 
as I know, the bfloat16_t name is only in C++.)

-- 
Joseph S. Myers
josmyers@redhat.com