remove footnote back-links to avoid duplicate anchors (#929)

Author: bashbaug

cxx/annotation.txt

@@ -6,19 +6,19 @@
 
 '''''
 [[ftn2]]
-<<ftnref2,[2]>> The `double` data type is an optional type that is supported if `CL_DEVICE_DOUBLE_FP_CONFIG` in table 4.3 for a device is not zero.
+[2] The `double` data type is an optional type that is supported if `CL_DEVICE_DOUBLE_FP_CONFIG` in table 4.3 for a device is not zero.
 
 [[ftn3]]
-<<ftnref3,[3]>> The question mark ? in numerical selector refers to special undefined component of vector; reading from it results in undefined value, writing to it is discarded.
+[3] The question mark ? in numerical selector refers to special undefined component of vector; reading from it results in undefined value, writing to it is discarded.
 
 [[ftn4]]
-<<ftnref4,[4]>> Only if the *cl_khr_fp16* extension is enabled and has been supported
+[4] Only if the *cl_khr_fp16* extension is enabled and has been supported
 
 [[ftn5]]
-<<ftnref5,[5]>> For conversions to floating-point format, when a finite source value exceeds the maximum representable finite floating-point destination value, the rounding mode will affect whether the result is the maximum finite floating-point value or infinity of same sign as the source value, per IEEE-754 rules for rounding.
+[5] For conversions to floating-point format, when a finite source value exceeds the maximum representable finite floating-point destination value, the rounding mode will affect whether the result is the maximum finite floating-point value or infinity of same sign as the source value, per IEEE-754 rules for rounding.
 
 [[ftn6]]
-<<ftnref6,[6]>> The `as_type<T>` function is intended to reflect the organization of data in register.
+[6] The `as_type<T>` function is intended to reflect the organization of data in register.
 The `as_type<T>` construct is intended to compile to no instructions on devices that use a shared register file designed to operate on both the operand and result types.
 Note that while differences in memory organization are expected to largely be limited to those arising from endianness, the register based representation may also differ due to size of the element in register.
 (For example, an architecture may load a char into a 32-bit register, or a char vector into a SIMD vector register with fixed 32-bit element size.)
@@ -27,91 +27,91 @@ So, for example if an implementation stores all single precision data as double
 If data stored in different address spaces do not have the same endianness, then the "dominant endianness" of the device should prevail.
 
 [[ftn7]]
-<<ftnref7,[7]>> `memory_order_consume` is not supported in OpenCL {cpp}
+[7] `memory_order_consume` is not supported in OpenCL {cpp}
 
 [[ftn8]]
-<<ftnref8,[8]>> This value for `memory_scope` can only be used with `atomic_fence` with flags set to `mem_fence::image`.
+[8] This value for `memory_scope` can only be used with `atomic_fence` with flags set to `mem_fence::image`.
 
 [[ftn9]]
-<<ftnref9,[9]>> We can't require {cpp14} atomics since host programs can be implemented in other programming languages and versions of C or {cpp}, but we do require that the host programs use atomics and that those atomics be compatible with those in {cpp14}.
+[9] We can't require {cpp14} atomics since host programs can be implemented in other programming languages and versions of C or {cpp}, but we do require that the host programs use atomics and that those atomics be compatible with those in {cpp14}.
 
 [[ftn10]]
-<<ftnref10,[10]>> The `atomic_long` and `atomic_ulong` types are supported if the *cl_khr_int64_base_atomics* and *cl_khr_int64_extended_atomics* extensions are supported and have been enabled.
+[10] The `atomic_long` and `atomic_ulong` types are supported if the *cl_khr_int64_base_atomics* and *cl_khr_int64_extended_atomics* extensions are supported and have been enabled.
 
 [[ftn11]]
-<<ftnref11,[11]>> The `atomic_double` type is only supported if double precision is supported and the *cl_khr_int64_base_atomics* and *cl_khr_int64_extended_atomics* extensions are supported and have been enabled.
+[11] The `atomic_double` type is only supported if double precision is supported and the *cl_khr_int64_base_atomics* and *cl_khr_int64_extended_atomics* extensions are supported and have been enabled.
 
 [[ftn12]]
-<<ftnref12,[12]>> If the device address space is 64-bits, the data types `atomic_intptr_t`, `atomic_uintptr_t`, `atomic_size_t` and `atomic_ptrdiff_t` are supported only if the *cl_khr_int64_base_atomics* and *cl_khr_int64_extended_atomics* extensions are supported and have been enabled.
+[12] If the device address space is 64-bits, the data types `atomic_intptr_t`, `atomic_uintptr_t`, `atomic_size_t` and `atomic_ptrdiff_t` are supported only if the *cl_khr_int64_base_atomics* and *cl_khr_int64_extended_atomics* extensions are supported and have been enabled.
 
 [[ftn13]]
-<<ftnref13,[13]>> The `\*_ms` types are supported only if the *cl_khr_gl_msaa_sharing* and *cl_khr_gl_depth_images* extensions are supported and have been enabled.
+[13] The `\*_ms` types are supported only if the *cl_khr_gl_msaa_sharing* and *cl_khr_gl_depth_images* extensions are supported and have been enabled.
 
 [[ftn14]]
-<<ftnref14,[14]>> Immediate meaning not side effects resulting from child kernels. The side effects would include stores to global memory and pipe reads and writes.
+[14] Immediate meaning not side effects resulting from child kernels. The side effects would include stores to global memory and pipe reads and writes.
 
 [[ftn15]]
-<<ftnref15,[15]>> This acts as a memory synchronization point between work-items in a work-group and child kernels enqueued by work-items in the work-group.
+[15] This acts as a memory synchronization point between work-items in a work-group and child kernels enqueued by work-items in the work-group.
 
 // Footnote 16 removed - duplicated footnote 17
 
 [[ftn17]]
-<<ftnref17,[17]>> i.e. the `global_work_size` values specified to `clEnqueueNDRangeKernel` are not evenly divisible by the `local_work_size` values for each dimension.
+[17] i.e. the `global_work_size` values specified to `clEnqueueNDRangeKernel` are not evenly divisible by the `local_work_size` values for each dimension.
 
 [[ftn18]]
-<<ftnref18,[18]>> Only if double precision is supported and has been enabled.
+[18] Only if double precision is supported and has been enabled.
 
 [[ftn19]]
-<<ftnref19,[19]>> Refer to the <<order-and-scope, _Memory order and scope_>> section for description of `memory_scope`.
+[19] Refer to the <<order-and-scope, _Memory order and scope_>> section for description of `memory_scope`.
 
 [[ftn20]]
-<<ftnref20,[20]>> The `min()` operator is there to prevent `fract(-small)` from returning 1.0.
+[20] The `min()` operator is there to prevent `fract(-small)` from returning 1.0.
 It returns the largest positive floating-point number less than 1.0.
 
 [[ftn21]]
-<<ftnref21,[21]>> fmin and fmax behave as defined by {cpp14} and may not match the IEEE 754-2008 definition for minNum and maxNum with regard to signaling NaNs.
+[21] fmin and fmax behave as defined by {cpp14} and may not match the IEEE 754-2008 definition for minNum and maxNum with regard to signaling NaNs.
 Specifically, signaling NaNs may behave as quiet NaNs.
 
 [[ftn22]]
-<<ftnref22,[22]>> The user is cautioned that for some usages, e.g. `mad(a, b, -a*b)`, the definition of `mad()` in the embedded profile is loose enough that almost any result is allowed from `mad()` for some values of `a` and `b`.
+[22] The user is cautioned that for some usages, e.g. `mad(a, b, -a*b)`, the definition of `mad()` in the embedded profile is loose enough that almost any result is allowed from `mad()` for some values of `a` and `b`.
 
 [[ftn23]]
-<<ftnref23,[23]>> Frequently vector operations need n + 1 bits temporarily to calculate a result.
+[23] Frequently vector operations need n + 1 bits temporarily to calculate a result.
 The rhadd instruction gives you an extra bit without needing to upsample and downsample. This can be a profound performance win.
 
 [[ftn24]]
-<<ftnref24,[24]>> The primary purpose of the printf function is to help in debugging OpenCL kernels.
+[24] The primary purpose of the printf function is to help in debugging OpenCL kernels.
 
 [[ftn25]]
-<<ftnref25,[25]>> Note that _0_ is taken as a flag, not as the beginning of a field width.
+[25] Note that _0_ is taken as a flag, not as the beginning of a field width.
 
 [[ftn26]]
-<<ftnref26,[26]>> The results of all floating conversions of a negative zero, and of negative values that round to zero, include a minus sign.
+[26] The results of all floating conversions of a negative zero, and of negative values that round to zero, include a minus sign.
 
 [[ftn27]]
-<<ftnref27,[27]>> When applied to infinite and NaN values, the -, +, and space flag characters have their usual meaning; the # and _0_ flag characters have no effect.
+[27] When applied to infinite and NaN values, the -, +, and space flag characters have their usual meaning; the # and _0_ flag characters have no effect.
 
 [[ftn28]]
-<<ftnref28,[28]>> Binary implementations can choose the hexadecimal digit to the left of the decimal-point character so that subsequent digits align to nibble (4-bit) boundaries.
+[28] Binary implementations can choose the hexadecimal digit to the left of the decimal-point character so that subsequent digits align to nibble (4-bit) boundaries.
 
 [[ftn29]]
-<<ftnref29,[29]>> No special provisions are made for multibyte characters.
+[29] No special provisions are made for multibyte characters.
 The behavior of printf with the _s_ conversion specifier is undefined if the argument value is not a pointer to a literal string.
 
 [[ftn30]]
-<<ftnref30,[30]>> Except for the embedded profile whether either round to zero or round to nearest rounding mode may be supported for single precision floating-point.
+[30] Except for the embedded profile whether either round to zero or round to nearest rounding mode may be supported for single precision floating-point.
 
 [[ftn31]]
-<<ftnref31,[31]>> The ULP values for built-in math functions `lgamma` and `lgamma_r` is currently undefined.
+[31] The ULP values for built-in math functions `lgamma` and `lgamma_r` is currently undefined.
 
 [[ftn32]]
-<<ftnref32,[32]>> 0 ulp is used for math functions that do not require rounding.
+[32] 0 ulp is used for math functions that do not require rounding.
 
 [[ftn33]]
-<<ftnref33,[33]>> On some implementations, `powr()` or `pown()` may perform faster than `pow()`.
+[33] On some implementations, `powr()` or `pown()` may perform faster than `pow()`.
 If `x` is known to be `>= 0`, consider using `powr()` in place of `pow()`, or if `y` is known to be an integer, consider using `pown()` in place of `pow()`.
 
 // Footnote 34 removed - duplicated footnote 32
 
 [[ftn35]]
-<<ftnref35,[35]>> Here `TYPE_MIN` and `TYPE_MIN_EXP` should be substituted by constants appropriate to the floating-point type under consideration, such as `FLT_MIN` and `FLT_MIN_EXP` for float.
+[35] Here `TYPE_MIN` and `TYPE_MIN_EXP` should be substituted by constants appropriate to the floating-point type under consideration, such as `FLT_MIN` and `FLT_MIN_EXP` for float.

cxx/lang/builtin_data_types.txt

@@ -47,7 +47,7 @@ The following data types are supported.
 | A 32-bit floating-point.
   The float data type must conform to the IEEE 754 single precision storage format.
 
-| `double` [[ftnref2]] <<ftn2,[2]>>
+| `double` <<ftn2,[2]>>
 | A 64-bit floating-point.
   The double data type must conform to the IEEE 754 double precision storage format.
 

cxx/numerical_compliance/edge_case_behavior.txt

@@ -143,4 +143,4 @@ If subnormals are flushed to zero, a device may choose to conform to the followi
 
 For clarity, subnormals or denormals are defined to be the set of representable numbers in the range 0 < x < `TYPE_MIN` and `-TYPE_MIN` < x < -0.
 They do not include {plusmn}0.
-A non-zero number is said to be sub-normal before rounding if after normalization, its radix-2 exponent is less than `(TYPE_MIN_EXP - 1)`. [[ftnref35]] <<ftn35,[35]>>
+A non-zero number is said to be sub-normal before rounding if after normalization, its radix-2 exponent is less than `(TYPE_MIN_EXP - 1)`. <<ftn35,[35]>>

cxx/numerical_compliance/relative_error_as_ulps.txt

@@ -25,15 +25,15 @@ Currently hosted at
 https://hal.inria.fr/inria-00070503/document[https://hal.inria.fr/inria-00070503/document].
 ====
 
-<<ulp_values_for_single_precision_builtin_math_functions,ULP values for single precision built-in math functions>> [[ftnref31]] <<ftn31,[31]>> table describes the minimum accuracy of single precision floating-point arithmetic operations given as ULP values.
+<<ulp_values_for_single_precision_builtin_math_functions,ULP values for single precision built-in math functions>> <<ftn31,[31]>> table describes the minimum accuracy of single precision floating-point arithmetic operations given as ULP values.
 The reference value used to compute the ULP value of an arithmetic operation is the infinitely precise result.
 
 [[ulp_values_for_single_precision_builtin_math_functions]]
 .ULP values for single precision built-in math functions
 [width="100%",cols="50%,50%",options="header"]
 |====
 | *Function*
-| *Min Accuracy - ULP values [[ftnref32]] <<ftn32,[32]>>*
+| *Min Accuracy - ULP values <<ftn32,[32]>>*
 
 | _x_ + _y_
 | Correctly rounded
@@ -696,7 +696,7 @@ The reference value used to compute the ULP value of an arithmetic operation is
   Undefined for x < 0 and non-integer y.
   Undefined for x < 0 and y outside the domain [-2^24^, 2^24^].
   For x > 0 or x < 0 and even y, derived implementations implement this as exp2( y * log2( fabs(x) ) ).
-  For x < 0 and odd y, derived implementations implement this as -exp2( y * log2( fabs(x) ) [[ftnref33]] <<ftn33,[33]>>.
+  For x < 0 and odd y, derived implementations implement this as -exp2( y * log2( fabs(x) ) <<ftn33,[33]>>.
   For x == 0 and nonzero y, derived implementations return zero.
   For non-derived implementations, the error is \<= 8192 ULP.
 

cxx/numerical_compliance/rounding_modes.txt

@@ -13,6 +13,6 @@ IEEE 754 defines four possible rounding modes:
   * Round toward -infinity.
   * Round toward zero.
 
-_Round to nearest even_ is currently the only rounding mode required [[ftnref30]] <<ftn30,[30]>> by the OpenCL specification for single precision and double precision operations and is therefore the default rounding mode.
+_Round to nearest even_ is currently the only rounding mode required <<ftn30,[30]>> by the OpenCL specification for single precision and double precision operations and is therefore the default rounding mode.
 In addition, only static selection of rounding mode is supported.
 Static and dynamic selection of rounding mode is not supported.

cxx/stdlib/atomic_operations.txt

@@ -386,11 +386,11 @@ enum memory_scope
 
 }
 ----
-An enumeration `memory_order` is described in section [atomics.order] of {cpp14} specification. [[ftnref7]] <<ftn7,[7]>>
+An enumeration `memory_order` is described in section [atomics.order] of {cpp14} specification. <<ftn7,[7]>>
 
 The enumerated type `memory_scope` specifies whether the memory ordering constraints given by `memory_order` apply to work-items in a work-group or work-items of a kernel(s) executing on the device or across devices (in the case of shared virtual memory). Its enumeration constants are as follows:
 
-  * `memory_scope_work_item` [[ftnref8]] <<ftn8,[8]>>
+  * `memory_scope_work_item` <<ftn8,[8]>>
   * `memory_scope_sub_group`
   * `memory_scope_work_group`
   * `memory_scope_device`
@@ -402,7 +402,7 @@ Atomic operations to local memory only guarantee memory ordering in the work-gro
 NOTE: With fine-grained system SVM, sharing happens at the granularity of individual loads and stores anywhere in host memory.
 Memory consistency is always guaranteed at synchronization points, but to obtain finer control over consistency, the OpenCL atomics functions may be used to ensure that the updates to individual data values made by
 one unit of execution are visible to other execution units.
-In particular, when a host thread needs fine control over the consistency of memory that is shared with one or more OpenCL devices, it must use atomic and fence operations that are compatible with the {cpp14} atomic operations [[ftnref9]] <<ftn9,[9]>>.
+In particular, when a host thread needs fine control over the consistency of memory that is shared with one or more OpenCL devices, it must use atomic and fence operations that are compatible with the {cpp14} atomic operations <<ftn9,[9]>>.
 
 [[atomic-lock-free-property]]
 ==== Atomic lock-free property
@@ -755,7 +755,7 @@ An application that wants to use 64-bit atomic types will need to define `cl_khr
 [[restrictions-3]]
 ==== Restrictions
 
-* The generic `atomic<T>` class template is only available if `T` is `int`, `uint`, `long`, `ulong` [[ftnref10]] <<ftn10,[10]>>, `float`, `double` [[ftnref11]] <<ftn11,[11]>>, `intptr_t` [[ftnref12]] <<ftn12,[12]>>, `uintptr_t`, `size_t`, `ptrdiff_t`.
+* The generic `atomic<T>` class template is only available if `T` is `int`, `uint`, `long`, `ulong` <<ftn10,[10]>>, `float`, `double` <<ftn11,[11]>>, `intptr_t` <<ftn12,[12]>>, `uintptr_t`, `size_t`, `ptrdiff_t`.
 * The `atomic_bool`, `atomic_char`, `atomic_uchar`, `atomic_short`, `atomic_ushort`, `atomic_intmax_t` and `atomic_uintmax_t` types are not supported by OpenCL {cpp}.
 * OpenCL {cpp} requires that the built-in atomic functions on atomic types are lock-free.
 * The atomic data types cannot be declared inside a kernel or non-kernel function unless they are declared as `static` keyword or in `local<T>` and `global<T>` containers.

cxx/stdlib/common.txt

@@ -11,7 +11,7 @@ Descriptions are always per-component.
 
 The built-in common functions are implemented using the round to nearest even rounding mode.
 
-Here `gentype` matches: `half__n__` [[ftnref4]] <<ftn4,[4]>>, `float__n__` or `double__n__` [[ftnref18]] <<ftn18,[18]>>
+Here `gentype` matches: `half__n__` <<ftn4,[4]>>, `float__n__` or `double__n__` <<ftn18,[18]>>
 
 [[header-opencl_common-synopsis]]
 ==== Header <opencl_common> Synopsis

cxx/stdlib/conversions.txt

@@ -48,7 +48,7 @@ T convert_cast(T const& arg);
 [[data-types]]
 ==== Data Types
 
-Conversions are available for the following scalar types: `bool`, `char`, `uchar`, `short`, `ushort`, `int`, `uint`, `long`, `ulong`, `half` [[ftnref4]] <<ftn4,[4]>>, `float`, `double`, and built-in vector types derived therefrom.
+Conversions are available for the following scalar types: `bool`, `char`, `uchar`, `short`, `ushort`, `int`, `uint`, `long`, `ulong`, `half` <<ftn4,[4]>>, `float`, `double`, and built-in vector types derived therefrom.
 The operand and result type must have the same number of elements.
 The operand and result type may be the same type in which case the conversion has no effect on the type or value of an expression.
 
@@ -70,7 +70,7 @@ Conversions may have an optional rounding mode specified as described in the tab
 | `rtn`           | Round toward negative infinity
 |====
 
-If a rounding mode is not specified, conversions to integer type use the `rtz` (round toward zero) rounding mode and conversions to floating-point type [[ftnref5]] <<ftn5,[5]>> uses the `rte` rounding mode.
+If a rounding mode is not specified, conversions to integer type use the `rtz` (round toward zero) rounding mode and conversions to floating-point type <<ftn5,[5]>> uses the `rte` rounding mode.
 
 [[out-of-range-behavior-and-saturated-conversions]]
 ==== Out-of-Range Behavior and Saturated Conversions

cxx/stdlib/device_enqueue.txt

@@ -416,8 +416,8 @@ It is defined as follows:
 | `no_wait`
     | Indicates that the enqueued kernels do not need to wait for the parent kernel to finish execution before they begin execution.
 | `wait_kernel`
-    | Indicates that all work-items of the parent kernel must finish executing and all immediate [[ftnref14]] <<ftn14,[14]>> side effects committed before the enqueued child kernel may begin execution.
-| `wait_work_group` [[ftnref15]] <<ftn15,[15]>>
+    | Indicates that all work-items of the parent kernel must finish executing and all immediate <<ftn14,[14]>> side effects committed before the enqueued child kernel may begin execution.
+| `wait_work_group` <<ftn15,[15]>>
     | Indicates that the enqueued kernels wait only for the work-group that enqueued the kernels to finish before they begin execution.
 |====