🌐 pot(main): update .pot from Sphinx

main/locale/pot/LC_MESSAGES/AMDGPUDwarfExtensionsForHeterogeneousDebugging.pot

@@ -8,7 +8,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: LLVM main\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2025-10-13 08:36+0000\n"
+"POT-Creation-Date: 2025-10-27 08:36+0000\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <[email protected]>\n"
@@ -59,7 +59,7 @@ msgstr ""
 msgid ""
 "The LLVM compiler has upstream support for commercially available AMD GPU "
 "hardware (AMDGPU) [:ref:`AMDGPU-LLVM <amdgpu-dwarf-AMDGPU-LLVM>`]. The open "
-"source ROCgdb [:ref:`AMD-ROCgdb <amdgpu-dwarf-AMD-ROCgdb>`] GDB based "
+"source ROCgdb [:ref:`AMD-ROCgdb <amdgpu-dwarf-AMD-ROCgdb>`] GDB-based "
 "debugger also has support for AMDGPU which is being upstreamed. Support for "
 "AMDGPU is also being added by third parties to the GCC [:ref:`GCC <amdgpu-"
 "dwarf-GCC>`] compiler and the Perforce TotalView HPC Debugger [:ref:"
@@ -68,7 +68,7 @@ msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:46
 msgid ""
-"To support debugging heterogeneous programs several features that are not "
+"To support debugging heterogeneous programs, several features that are not "
 "provided by current DWARF Version 5 [:ref:`DWARF <amdgpu-dwarf-DWARF>`] have "
 "been identified. The :ref:`amdgpu-dwarf-extensions` section gives an "
 "overview of the extensions devised to address the missing features. The "
@@ -160,7 +160,7 @@ msgid ""
 "DWARF Version 5 does not allow location descriptions to be entries on the "
 "DWARF expression stack. They can only be the final result of the evaluation "
 "of a DWARF expression. However, by allowing a location description to be a "
-"first-class entry on the DWARF expression stack it becomes possible to "
+"first-class entry on the DWARF expression stack, it becomes possible to "
 "compose expressions containing both values and location descriptions "
 "naturally. It allows objects to be located in any kind of memory address "
 "space, in registers, be implicit values, be undefined, or a composite of any "
@@ -184,12 +184,12 @@ msgstr ""
 msgid ""
 "For those familiar with the definition of location descriptions in DWARF "
 "Version 5, the definitions in these extensions are presented differently, "
-"but does in fact define the same concept with the same fundamental "
-"semantics. However, it does so in a way that allows the concept to extend to "
-"support address spaces, bit addressing, the ability for composite location "
+"but do in fact define the same concept with the same fundamental semantics. "
+"However, it does so in a way that allows the concept to extend to support "
+"address spaces, bit addressing, the ability for composite location "
 "descriptions to be composed of any kind of location description, and the "
 "ability to support objects located at multiple places. Collectively these "
-"changes expand the set of architectures that can be supported and improves "
+"changes expand the set of architectures that can be supported and improve "
 "support for optimized code."
 msgstr ""
 
@@ -201,7 +201,7 @@ msgid ""
 "optimized GPU and non-GPU code. Examining the GDB debugger and LLVM "
 "compiler, it appears only to require modest changes as they both already "
 "have to support general use of location descriptions. It is anticipated that "
-"will also be the case for other debuggers and compilers."
+"this will also be the case for other debuggers and compilers."
 msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:142
@@ -232,7 +232,7 @@ msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:159
 msgid ""
-"CFI describes restoring callee saved registers that are spilled. Currently "
+"CFI describes restoring callee saved registers that are spilled. Currently, "
 "CFI only allows a location description that is a register, memory address, "
 "or implicit location description. AMDGPU optimized code may spill scalar "
 "registers into portions of vector registers. This requires extending CFI to "
@@ -329,7 +329,7 @@ msgid ""
 "series of positive and negative offsets that may transiently overflow or "
 "underflow, but end up in range. This is simple for the arithmetic operations "
 "as they are defined in terms of two's complement arithmetic on a base type "
-"of a fixed size. Therefore, the offset operation define that integer "
+"of a fixed size. Therefore, the offset operation defines that integer "
 "overflow is ill-formed. This is in contrast to the ``DW_OP_plus``, "
 "``DW_OP_plus_uconst``, and ``DW_OP_minus`` arithmetic operations which "
 "define that it causes wrap-around."
@@ -533,7 +533,7 @@ msgstr ""
 msgid ""
 "The ``DW_OP_LLVM_form_aspace_address`` (see :ref:`amdgpu-dwarf-memory-"
 "location-description-operations`) operation is defined to create a memory "
-"location description from an address and address space. If can be used to "
+"location description from an address and address space. It can be used to "
 "specify the location of a variable that is allocated in a specific address "
 "space. This allows the size of addresses in an address space to be larger "
 "than the generic type. It also allows a consumer great implementation "
@@ -549,7 +549,7 @@ msgid ""
 "defined to produce a value, and an implicit conversion to a memory location "
 "description was defined, then it would be limited to the size of the generic "
 "type (which matches the size of the default address space). An "
-"implementation would likely have to use *reserved ranges* of value to "
+"implementation would likely have to use *reserved ranges* of values to "
 "represent different address spaces. Such a value would likely not match any "
 "address value in the actual hardware. That would require the consumer to "
 "have special treatment for such values."
@@ -778,10 +778,10 @@ msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:531
 msgid ""
-"For efficiency, the expression calculates the source location the wavefront "
-"as a whole. This can be done using the ``DW_OP_LLVM_select_bit_piece`` (see :"
-"ref:`amdgpu-dwarf-operation-to-create-vector-composite-location-"
-"descriptions`) operation."
+"For efficiency, the expression calculates the source location of the "
+"wavefront as a whole. This can be done using the "
+"``DW_OP_LLVM_select_bit_piece`` (see :ref:`amdgpu-dwarf-operation-to-create-"
+"vector-composite-location-descriptions`) operation."
 msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:536
@@ -838,7 +838,7 @@ msgid ""
 "architecture specific information in the debugging information entries of "
 "that compilation unit. This allows a consumer to know what extensions are "
 "present in the debugger information entries as is possible with the "
-"augmentation string of other sections. See ."
+"augmentation string of other sections."
 msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:569
@@ -865,8 +865,8 @@ msgstr ""
 msgid ""
 "AMDGPU supports programming languages that include online compilation where "
 "the source text may be created at runtime. For example, the OpenCL and HIP "
-"language runtimes support online compilation. To support is, a way to embed "
-"the source text in the debug information is provided."
+"language runtimes support online compilation. To support this, a way to "
+"embed the source text in the debug information is provided."
 msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:587
@@ -880,15 +880,15 @@ msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:592
 msgid ""
-"In DWARF Version 5 the file timestamp and file size can be optional, but if "
-"the MD5 checksum is present it must be valid for all files. This is a "
+"In DWARF Version 5, the file timestamp and file size can be optional, but if "
+"the MD5 checksum is present, it must be valid for all files. This is a "
 "problem if using link time optimization to combine compilation units where "
-"some have MD5 checksums and some do not. Therefore, sSupport to allow MD5 "
-"checksums to be optionally present in the line table is added."
+"some have MD5 checksums, and others do not. Therefore, the line table is "
+"extended to allow MD5 checksums to be optional."
 msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:601
-msgid "2.18 Add the HIP Programing Language"
+msgid "2.18 Add the HIP Programming Language"
 msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:603
@@ -921,7 +921,7 @@ msgstr ""
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:619
 msgid ""
 "Note that although this is similar to SIMT execution, the way a client "
-"debugger uses the information is fundamentally different. In SIMT execution "
+"debugger uses the information is fundamentally different. In SIMT execution, "
 "the debugger needs to present the concurrent execution as distinct source "
 "language threads that the user can list and switch focus between. With "
 "iteration concurrency optimizations, such as software pipelining and "
@@ -970,7 +970,7 @@ msgid ""
 "It is common in SIMD vectorization for the compiler to generate code that "
 "promotes portions of an array into vector registers. For example, if the "
 "hardware has vector registers with 8 elements, and 8 wide SIMD instructions, "
-"the compiler may vectorize a loop so that is executes 8 iterations "
+"the compiler may vectorize a loop so that it executes 8 iterations "
 "concurrently for each vectorized loop iteration."
 msgstr ""
 
@@ -1029,7 +1029,7 @@ msgstr ""
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:693
 msgid ""
 "Considering the location of ``dst`` and ``src`` in the loop body, the "
-"elements ``dst[i]`` and ``src[i]`` would be located in registers, all other "
+"elements ``dst[i]`` and ``src[i]`` would be located in registers; all other "
 "elements are located in memory. Let register ``R0`` contain the base address "
 "of ``dst``, register ``R1`` contain ``i``, and register ``R2`` contain the "
 "registerized ``dst[i]`` element. We can describe the location of ``dst`` as "
@@ -1044,7 +1044,7 @@ msgstr ""
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:724
 msgid ""
 "AMDGPU supports languages, such as OpenCL, that define source language "
-"memory spaces. Support is added to define language specific memory spaces so "
+"memory spaces. Support is added to define language-specific memory spaces so "
 "they can be used in a consistent way by consumers. See :ref:`amdgpu-dwarf-"
 "memory-spaces`."
 msgstr ""
@@ -1068,12 +1068,12 @@ msgid ""
 "registry and a desire for backwards compatibility means vendor extensions "
 "are never retired, even when standard versions are accepted into DWARF "
 "proper. This has produced a situation where the effective encoding space "
-"available for new vendor extensions is miniscule today."
+"available for new vendor extensions is minuscule today."
 msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:743
 msgid ""
-"To expand this encoding space a new DWARF operation ``DW_OP_LLVM_user`` is "
+"To expand this encoding space, a new DWARF operation ``DW_OP_LLVM_user`` is "
 "added which acts as a \"prefix\" for vendor extensions. It is followed by a "
 "ULEB128 encoded vendor extension opcode, which is then followed by the "
 "operands of the corresponding vendor extension operation."
@@ -1119,7 +1119,7 @@ msgstr ""
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:778
 msgid ""
 "Notes are included to describe how the changes are to be applied to the "
-"DWARF Version 5 standard. They also describe rational and issues that may "
+"DWARF Version 5 standard. They also describe rationale and issues that may "
 "need further consideration."
 msgstr ""
 
@@ -1400,7 +1400,7 @@ msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:901
 msgid ""
-"The 0 based SIMT lane identifier to be used in evaluating a user presented "
+"The 0-based SIMT lane identifier to be used in evaluating a user presented "
 "expression. This applies to source languages that are implemented for a "
 "target architecture using a SIMT execution model. These implementations map "
 "source language threads of execution to lanes of the target architecture "
@@ -1433,7 +1433,7 @@ msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:920
 msgid ""
-"The 0 based source language iteration instance to be used in evaluating a "
+"The 0-based source language iteration instance to be used in evaluating a "
 "user presented expression. This applies to target architectures that support "
 "optimizations that result in executing multiple source language loop "
 "iterations concurrently."
@@ -2892,7 +2892,7 @@ msgstr ""
 
 #: ../../../AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst:1848
 msgid ""
-"GDB has a per register hook that allows a target specific conversion on a "
+"GDB has a per register hook that allows a target-specific conversion on a "
 "register by register basis. It defaults to truncation of bigger registers. "
 "Removing use of the target hook does not cause any test failures in common "
 "architectures. If the compiler for a target architecture did want some form "
@@ -2905,7 +2905,7 @@ msgid ""
 "If T is a larger type than the register size, then the default GDB register "
 "hook reads bytes from the next register (or reads out of bounds for the last "
 "register!). Removing use of the target hook does not cause any test failures "
-"in common architectures (except an illegal hand written assembly test). If a "
+"in common architectures (except an illegal hand-written assembly test). If a "
 "target architecture requires this behavior, these extensions allow a "
 "composite location description to be used to combine multiple registers."
 msgstr ""
@@ -3543,7 +3543,7 @@ msgid ""
 "The implicit conversion could also be defined as target architecture "
 "specific. For example, GDB checks if V is an integral type. If it is not it "
 "gives an error. Otherwise, GDB zero-extends V to 64 bits. If the GDB target "
-"defines a hook function, then it is called. The target specific hook "
+"defines a hook function, then it is called. The target-specific hook "
 "function can modify the 64-bit value, possibly sign extending based on the "
 "original value type. Finally, GDB treats the 64-bit value V as a memory "
 "location address."