The ``ENTRY`` record (code 2) contains a variable number of values describing a
unique set of function parameter attributes. Each *attrgrp* value is used as a
-key with which to look up an entry in the the attribute group table described
+key with which to look up an entry in the attribute group table described
in the ``PARAMATTR_GROUP_BLOCK`` block.
.. _PARAMATTR_CODE_ENTRY_OLD:
- ``DW_OP_plus_uconst, 93`` adds ``93`` to the working expression.
- ``DW_OP_LLVM_fragment, 16, 8`` specifies the offset and size (``16`` and ``8``
here, respectively) of the variable fragment from the working expression. Note
- that contrary to DW_OP_bit_piece, the offset is describing the the location
+ that contrary to DW_OP_bit_piece, the offset is describing the location
within the described source variable.
- ``DW_OP_swap`` swaps top two stack entries.
- ``DW_OP_xderef`` provides extended dereference mechanism. The entry at the top
This function returns the nonnegative square root of the specified value.
If the value is less than negative zero, a floating point exception occurs
-and the the return value is architecture specific.
+and the return value is architecture specific.
'``llvm.experimental.constrained.pow``' Intrinsic
Function definitions and calls also work, but something went very wrong on that
last line. The call looks valid, so what happened? As you may have guessed from
-the the API a Module is a unit of allocation for the JIT, and testfunc was part
+the API a Module is a unit of allocation for the JIT, and testfunc was part
of the same module that contained anonymous expression. When we removed that
module from the JIT to free the memory for the anonymous expression, we deleted
the definition of ``testfunc`` along with it. Then, when we tried to call