[Patch Doc] Update documentation for __fp16 type

[Sandra Loosemore]

On 12/15/2016 03:27 AM, Jakub Jelinek wrote:
> On Thu, Dec 15, 2016 at 11:23:14AM +0100, Andreas Schwab wrote:
>> On Dez 15 2016, Jakub Jelinek <jakub@redhat.com> wrote:
>>
>>> So, shall we change also the first 3?
>>
>> Yes, I'd think so.
>
> So here is it in patch form.  Is this ok for trunk?
>
> 2016-12-15  Jakub Jelinek  <jakub@redhat.com>
>
> 	* doc/extend.texi: Clean up @xref{...} uses.
> 	* doc/invoke.texi: Likewise.
>
> --- gcc/doc/extend.texi.jj	2016-12-14 20:28:12.000000000 +0100
> +++ gcc/doc/extend.texi	2016-12-15 11:26:07.867736292 +0100
> @@ -1057,7 +1057,7 @@ implements conversions between @code{__f
>   calls.
>
>   It is recommended that portable code use the @code{_Float16} type defined
> -by ISO/IEC TS 18661-3:2015 (@xref{Floating Types}).
> +by ISO/IEC TS 18661-3:2015.  @xref{Floating Types}.
>
>   @node Decimal Float
>   @section Decimal Floating Types
> @@ -2089,7 +2089,7 @@ union foo f = @{ .d = 4 @};
>   converts 4 to a @code{double} to store it in the union using
>   the second element.  By contrast, casting 4 to type @code{union foo}
>   stores it into the union as the integer @code{i}, since it is
> -an integer.  (@xref{Cast to Union}.)
> +an integer.  @xref{Cast to Union}.
>
>   You can combine this technique of naming elements with ordinary C
>   initialization of successive elements.  Each initializer element that
> @@ -2181,7 +2181,7 @@ specified is a union type.  You can spec
>   @code{union} keyword or with a @code{typedef} name that refers to
>   a union.  A cast to a union actually creates a compound literal and
>   yields an lvalue, not an rvalue like true casts do.
> -(@xref{Compound Literals}.)
> +@xref{Compound Literals}.
>
>   The types that may be cast to the union type are those of the members
>   of the union.  Thus, given the following union and variables:
> --- gcc/doc/invoke.texi.jj	2016-12-15 10:26:15.000000000 +0100
> +++ gcc/doc/invoke.texi	2016-12-15 11:25:19.226386092 +0100
> @@ -7262,8 +7262,8 @@ release to an another.
>   @opindex fno-keep-inline-dllexport
>   This is a more fine-grained version of @option{-fkeep-inline-functions},
>   which applies only to functions that are declared using the @code{dllexport}
> -attribute or declspec (@xref{Function Attributes,,Declaring Attributes of
> -Functions}.)
> +attribute or declspec.  @xref{Function Attributes,,Declaring Attributes of
> +Functions}.
>
>   @item -fkeep-inline-functions
>   @opindex fkeep-inline-functions
>

This is OK, but FYI it would have been simpler just to do

s/@xref/@pxref/

in the one instance that was causing an diagnostic.  Sorry I missed that 
in the original patch review.  :-(

-Sandra